distributed_system

分布式系统学习

"微服务的惯用架构"

Posted by yueLng on 2018-08-01

what‘t distributed

“A distributed system is a model in which components located on networked computers communicate and coordinate their actions by passing messages.” – Wikipedia

CAP 理论

  1. 一致性 all nodes see the same data at the same time
    数据一致性可以从客户端和服务端两个角度看，客户端角度的一致性指多并发访问更新后的数据如何获取的问题，服务端指更新如何复制到整个系统。通常包括三种一致性策略，强一致性，弱一致性，最终一致性，CAP中的C指的是最终一致性

  2. 可用性 Reads and writes always succeed
    可用性是指系统能够正常提供服务，不出现用户操作失败或者访问超时的情况

  3. 分区容错性 the system continues to operate despite arbitrary message loss or failure of part of the system
    当分布式系统遇到某节点或者网络分区故障的时候，任能对外满足一致性或可用性的服务，简单来说，如果在网络中断，消息丢失的情况下，系统还能正常工作，这就是有比较好的分区容错性

如何证明CAP理论

数据库两个从库的例子，满足一致性，表示两个从库的数据一致，可用性表示，请求两个从库都立即响应，分区容错的情况下，任一从库宕机，不会影响其他从库的正常工作
两个从库的设计 大前提就是我们需要容忍任一从库宕机的可能，所以首先要满足分区容错性，当两从库之间数据同步失败，这时我们就需要在一致性和可用性之间做出选择，选择数据一致性，牺牲可用性，阻塞等待，直达数据一致，选择可用性，牺牲一致性，响应旧的的数据。
综上所述，在分区容错的前提下，我们只能在可用性和一致性选择一个。

CAP权衡

  • CA without P
    无法通过降低CA来提升P，要想提升P，需要提升基础设施的稳定性来保障。
  • CP without A
    分布式数据库大多被设计成CP，在极端情况下，优先保证数据的强一致性，牺牲可用性，例如Redis，etcd，zookeeper、hbase，在不保证可用性的情况下，需要客户端重试请求才能获得正确结果
  • AP without C
    在牺牲数据一致性的情况下，提供高可用，使用最终一致性。数据库主从，当主从存在延时，就必然存在数据不一致问题。在对数据一致性要求很高的情况下，例如支付金融业务，其他情况是可以牺牲一致性的，做到最终一致性即可。

Eventual Consistency

分布式数据库必须要有 分区容忍性(Partition Tolerant)，所以主要是在 一致性(Consistent) 和 可用性(Available) 之间做选择。 虽然在 CAP 理论中，选择了 Availability 就不可能得到真正的 Consistency，但是你可以追求 最终一致性(Evental Consistency)

evental Consistency 背后的思路是：每个系统节点总是 Available 的，同时任何的写(修改数据)操作都会在后台同步给系统的其他节点。 这意味着，在任意时刻，整个系统是Inconsistent(不一致的)，然而从概率上讲，大多数的请求得到的值是准确的。

互联网的 DNS(域名服务) 就是最终一致性的一个非常好的例子。你注册了一个域名， 这个新域名需要几天的时间才能通知给所有的 DNS 服务器。但是不管什么时候，你能够连接到的任意 DNS 服务器对你来说都是 ‘Available’ 的。

The Twelve Factor App

The Twelve Factor App
网关聚合服务 提供restful接口
grpc 内网调用
服务发现，使用etcd自动服务注册
服务配置，使用etcd存储配置
服务快速部署
服务logging记录
服务调用链的追踪
服务质量的监控，响应时间
缓存的应用

架构

总体而言设计思想是SOA,Public/Private APIs 用 RESTful，不同的service独立性很高。
CAP，一致性，可用性，可靠性，一般取后两者。
优化架构

  • 数据存储，活跃数据与非活跃数据
  • 索引，lucene或者solr
  • 事件响应，Queuing&Push Notification，activeMQ
  • 缓存策略，不同层次的缓存，代理缓存。
  • 内容压缩，google的压缩算法，或者序列化和反序列化框架
  • 通信协议，xmpp，json或者thrift
  • 内容编码，FFMPEG
  • 安全，严格控制内部权限。
  • The log

消息队列

消息队列的几个优势

  1. 解耦，允许独立扩展或修改两边的处理过程
  2. 冗余，插入-获取-删除，只有确定数据被处理，才会将数据从队列中移除
  3. 扩展性，由于解耦了处理过程，所以很方便扩展输入和输出
  4. 可恢复性，当一个消息处理进程挂了，也不会影响全局
  5. 灵活性&峰值处理能力，
  6. 送达保证，每个消息只能被处理一次，除非客户端明确表示已经处理完这个消息，否则会放回队列，在可配置时间后再次处理
  7. 排序保证，保证数据按照特定的顺序进行处理
  8. 缓冲
  9. 理解数据流
  10. 异步通信

数据科学

Flume + Kafka + Strom + Hbase

  • 挖掘和理解用户的商业需求，通过产品创新和数据分析，促进产品成长；
  • 海量日志的处理与分析经验；
  • 数据分析系统架构搭建经验；
  • 前端、后端、服务器、产品经验

网络编程

  • redis 是单线程异步网络编程的范例，带注释的redis：huangz1990/annotated_redis_source · GitHub
  • nginx 多进程网络编程的巅峰，模块化
  • memcached 虽然是C++，但是C style的，多线程网络编程的巅峰
  • 熟悉和理解异步开发框架或模型

RPC

RPC通讯框架Thrift

参考资料

CATALOG
    FEATURED TAGS
    distributed_system
    FRIENDS