相对于单机架构系统,分布式系统可以从以下三个方面获得收益和增强:
- 扩展性:系统对所要处理的持续增长的任务的适应能力和兼容能力
- 集群规模扩展性:整体服务性能可以随集群机器数量线性增长
- 地理扩展性:能够使用不同地区的数据中心以抵消地理因素带来的延迟
- 管理扩展性:集群数量的上升不会导致管理复杂度快速上升
- 性能
- 短RT
- 低延迟
- 高吞吐和较低的计算资源占用率
- 可用性
- 可用性=可用时间/(可用时间+不可用时间),可用性百分比越高,难度越高。提升系统可用性的关键一点:在设计阶段就需要考虑容错性(Fault tolerance) ,即“面向失败的设计”。
根据不同的场景大体分为分布式服务、分布式消息、分布式缓存、分布式调度、分布式数据库、分布式搜索、分布式事务以及分布式计算8种: (绿色是我用过的比较熟悉的,因此就介绍一下我熟悉的)
RPC
RPC(Remote Process Call),即远程服务调用,被广泛地应用在很多企业应用中,是早期主要的服务治理方案,其流程较为简单,客户端consumer携带参数发送RPC请求到服务提供方provider,provider根据参数路由到具体函数,方法,并将执行获得的结果返回,至此一次RPC调用完成。
HSF (High-speed Service Framework),高速服务框架是阿里的分布式 RPC 服务框架。
MetaQ
MetaQ是一款分布式、队列模型的消息中间件。基于发布订阅模式,有Push和Pull两种消费方式,支持严格的消息顺序,亿级别的堆积能力,支持消息回溯和多个维度的消息查询。
MetaQ物理模型
各组件功能:
- Name Server:注册服务器,需要将topic注册到上面
- Broker:存储转发服务器(消息存储地),每个broker需要与所有的name server建立长连接,从而获取topic信息;分为master和容灾的slaver
- Producer:消息发送方,需要与其中一个name server建立连接,获得路由信息,再与主题对应的broker建立长连接且定时向master发送心跳;消息由producer发送到master,再由master同步到所有broker
- Consumer:消息接收方,需要与其中一个name server建立连接,获得路由信息,再向提供服务的master、slaver建立长连接,具体接收消息时刻选择broker
MetaQ存储结构
metaq的逻辑存储结构是一种物理队列+逻辑队列的结构。
消息的存储格式可以参考这个:Kafka消息(存储)格式及索引组织方式
物理队列只有一个,采用固定大小的文件顺序存储消息。逻辑队列有多个,每个逻辑队列有多个分区,每个分区有多个索引。
- 消息顺序写入物理文件里面,每个文件达到一定的大小,新建一个文件继续顺序写数据(消息的写入是串行的,避免了磁盘竞争)
- 消息的索引则顺序的写入逻辑文件中,并不存放真正的消息,只是存放指向消息的索引。 metaq对于客户端展现的是逻辑队列就是消费队列,consumer从消费队列里顺序取消息进行消费。
这种设计是把物理和逻辑分离,消费队列更加轻量化。所以metaq可以支撑更多的消费队列数,提升消息的吞吐量,并且有一定的消息堆积能力。
缺点 : 写虽然是顺序写,但是读却是随机读的 解决办法 :尽可能让读命中pageCache,减少磁盘IO次数, metaq的所有消息都是持久化的,先写入系统PAGECACHE(页高速缓存),然后刷盘,可以保证内存与磁盘都有一份数据,访问时,直接从内存读取。 刷盘策略分为异步和同步两种。
Tair
Tair是一个类似于map的key/value结构存储系统(也就是缓存系统),具备标准的特性是:高性能、高扩展、高可靠,也就是传说中的三高产品,支持分布式集群部署。
- 高性能
- 基于高速缓存、内存或者ssd
- 高扩展
- 轻量中间件+三种数据引擎+负载均衡
- 高可用
- 各种容灾部署方式和解决方案
Tair的主要功能:
- 数据库缓存
- 作为数据库与dao层之间的中间缓存,降低对后端数据库的访问压力,高速缓存能使得访问速度达到1ms级别,例如高频率的数据库查询;
- 临时数据存储
- 应用程序需要维护大量临时数据,将临时数据存储在mdb中,可以降低内存管理的开销,改进应用程序工作负载。例如:在分布式系统中,同一个用户的不同请求可能会发送到不同的服务器上,这时可以用mdb作为全局存储,用于保存Session数据、用户的Token、权限信息等数据。【通常将缓存和临时数据存储统称为“非持久化存储”】
- 持久化存储
- 此时类似于传统的数据库,将数据存入磁盘中做持久化存储,例如广告推荐类需要离线计算大量数据以及榜单的生成(注意:由于此时采用的数据库引擎ldb是NoSQL类型的,所以不支持sql查询)