软负载——分布式系统的引路人
综述
软负载是分布式系统中极为普遍的技术之一。在分布式环境中，为了保证高可用性，通常同一个应用或同一个服务的提供方都会部署多份，以达到对等服务。而软负载就像一个引路人，帮助服务的消费者在这些对等的服务中合理地选择一个来执行相关的业务逻辑。
1.1、ConfigServer
ConfigServer主要提供非持久配置的发布和订阅。07/08年间在淘宝内部开发使用的时候，由于ZooKeeper还没有开源，不然可能会基于ZooKeeper来进行改造。主要使用场景是为分布式服务框架提供软负载功能所必须的服务地址列表。
结合淘宝业务场景的发展，与ZooKeeper相比主要有以下一些特点：
- ConfigServer基于无Master架构ConfigServer是无中心化的架构，不存在单点问题，通过特定的算法进行数据增量同步。
- ConfigServer支持数据的自动聚合配置数据的聚合功能是ConfigServer结合淘宝的使用场景开发的特殊功能，主要使用场景：集群服务地址发现。每台机器向ConfigServer注册自己的服务元信息，ConfigServer会根据服务名和分组自动聚合所有元数据，提供给服务订阅方使用。
- ConfigServer是推数据的模型ConfigServer的服务端与客户端是基于长连接的方式进行通信，在客户端订阅关系确定后，配置信息一旦发生变化，会主动推送配置数据到客户端，并回调客户端的业务监听器。
- ConfigServer客户端本地容灾ConfigServer客户端在收到配置数据时，会记录到本地容灾文件中。在ConfigServer服务端不可用的时候，应用继续使用内存中数据；即使应用这时候重启，ConfigServer的客户端使用本地容灾文件进行离线启动。
1.2、ConfigServer双11准备与优化
面对双11巨大的网站请求，对ConfigServer的数据推送环节考验尤其巨大，如何稳定、高效且正确的完成数据推送任务，成为双11前夕困扰ConfigServer团队最大的问题。在平时的正常运行中，ConfigServer管理的配置数据和订阅者数量已经达到一定量级，服务端的一次重启可能会引起大量的数据推送。举例来说：交易的某个服务有2000台，每个服务发布者信息200B，订阅者5000个，那么这个交易服务可用地址列表有变动，会产生2GB(2000*200B*5000)的数据推送。交易的应用有很多个服务，如果应用发布或者重启，会瞬间产生巨大的流量将ConfigServer服务端的网卡压满。当网卡压满后：保持长连接的心跳检测包会超时，导致与客户端的连接会持续在一个不稳定的状态，集群间数据同步也会受影响。
针对这个问题， ConfigServer在推送数据上做了两个方面的优化：
- 流量控制加入出口流量统计和监控，通过严格限制出口流量预留出足够的带宽给维持心跳和集群数据同步。这样即使有数据堆积，只会暂时的影响到数据推送，客户端的连接不会频繁的断开，集群之间的同步也不会受到影响。
- 减少推送量出于两方面考虑：压缩数据对代码的侵入不大；ConfigServer服务端CPU相对空闲，最终我们采用压缩数据的方式来减小数据包。我们经过对比主流的压缩算法（huffman，defalte，BZip2，LZMA）对真实推送数据的压缩测试，最终选择deflate算法。该功能上线后的检测结果显示1500M的推送数据最终推送大小为170M。效果很明显。
1.3、Diamond
Diamond主要提供持久配置的发布和订阅服务，最大特点是结构简单，稳定可靠。Diamond的主要使用场景是用来进行动态数据库切换与扩容，进行一些业务系统运行时开关配置的推送。Diamond产品专注于高可用性，基于此在架构、容灾机制、数据获取模型上有一些与同类产品的不同之处。
Diamond结构非常简单，也属于是无单点的架构模型，如图1-1所示。
图1-1-Diamond架构模型
发布或者更新配置数据时，步骤如下：
- 写入MySql数据库
- 写本地磁盘
- 通知集群其他机器去数据库dump更新的数据
订阅方获取配置数据时，直接读取服务端本地磁盘文件，尽量减少对数据库压力。
这种架构用短暂的延时换取最大的性能和一致性，一些配置不能接受延时的情况下，通过API可以获取数据库中的最新配置。
容灾机制
Diamond作为一个分布式环境下的持久配置系统，有一套完备的容灾机制，数据存储在：数据库、服务端磁盘、客户端缓存目录以及可以手工干预的容灾目录。客户端通过API获取配置数据按照固定的顺序去不同的数据源获取数据：容灾目录->服务端磁盘->客户端缓存。因此，面对如下情况，Diamond均能很好的应对：
- 数据库主库不可用，可以切换到备库，Diamond继续提供服务
- 数据库主备库全部不可用，Diamond通过本地缓存可以继续提供读服务
- 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端使用缓存目录继续运行，支持离线启动
- 数据库主备库全部不可用，Diamond服务端全部不可用，Diamond客户端缓存数据被删，可以通过拷贝备份的缓存目录到容灾目录下继续使用
综上所述，只有在同时碰到如下四个条件的情况下，客户端应用才无法启动： 数据库主备库全部不可用、Diamond服务端全部不可用、Diamond客户端缓存被清空、客户端没有备份的缓存文件。
1.4、Diamond双11准备与优化
长轮询改造
客户端采用推拉结合的策略在长连接和短连接之间取得一个平衡，让服务端不用太关注连接的管理，又可以获得长连接的及时性。
- 客户端发起一个对比请求到服务端，请求中包含客户端订阅的数据的指纹
- 服务端检查客户端的指纹是否与最新数据匹配
- 如果匹配，服务端持有连接
- 如果30秒内没有相关数据变化，服务端持有连接30秒后释放
- 如果30秒内有相关数据变化，服务端立即返回变化数据的ID
- 如果不匹配，立即返回变化数据的ID
- 客户端根据变化数据的ID去服务端获取最新的内容
Diamond通过这种多重容灾机制以及推拉结合的方式，让客户端逻辑尽量简单，而且高效稳定，使其成为名副其实的“钻石”。
小结
软负载系统引导着分布式请求的来龙去脉，管理着分布式离散数据的聚合与分发，成为了合理且最大化使用分布式系统资源的保证。在2013年的双11购物狂欢节中，面对巨大的消费者请求，ConfigServer集群共10台机器，支撑近60,000长连接，发布配置总量700,000条，订阅配置总量3,000,000条，数据推送峰值600MB/S。Diamond集群共48台，90,000条非聚合配置，380,000条聚合配置，TPS高峰期间达到18000，数据变更15000次，客户端感知最大延时小于2秒。双十一当天部分数据库做了切换，用户完全没有感知。
系列文章：
《中间件技术及双十一实践之中间件总体介绍》http://jm-blog.aliapp.com/?p=3359
《中间件技术及双十一实践之软负载篇》http://jm-blog.aliapp.com/?p=3450