2 分布式系统基础设施
一个大型、成熟的分布式系统的背后，往往会涉及众多的支撑系统，也即所谓的分布式系统的基础设施，如第一章介绍过的分布式协作及配置管理系统Zookeeper，还有本章将要介绍的分布式缓存系统、持久化存储系统、分布式消息系统、搜索引擎，另外还有CDN系统、负载均衡系统、运维自动化系统等等。
本章一共分为四个小节，分别介绍了分布式缓存，持久化存储，分布式消息系统和垂直化搜索引擎。
2.1 分布式缓存
分布式缓存主要用于在高并发环境下减轻数据库的压力，提高系统的响应速度和并发吞吐。常用的分布式缓存方案有memcache、redis等。
Memcache既可以在单台机器上使用，也可以作为分布式缓存系统使用。Memcache使用key-value形式存储和访问数据，在内存中维护一张巨大的HashTable，使得对数据查询的时间复杂度降低到O(1)。内存的空间是有限的，当内存没有更多的空间来存储新的数据时，memcache就会使用LRU（Least Recently Used）算法将最近不常访问的数据淘汰掉。
作为分布式缓存系统使用时，需要安装服务器端，具体的memcache分布式缓存系统搭建过程和使用方式网上资料很多。
2.1.1 分布式缓存应用
分布式缓存最典型的应用之一就是分布式session。
对于大型分布式网站来说，后端服务器是一个分布式集群，请求在不同服务器之间跳转。那么如何保持分布式环境下的session同步呢？传统网站一般通过将一部分数据存储在cookie中来规避分布式环境下session的操作，但是这样做得弊端很多，一方面cookie的安全性不高，另一方面cookie存储数据的大小是有限制的。随着移动互联网的发展，很多情况下还得兼顾移动端的session需求，使得采用cookie进行session同步的方式更显弊端，于是才产生了分布式session。
分布式session有两种方案，一种是持久化存储到DB中，可以保证宕机时会话不易丢失，但系统整体吞吐会受到影响。另一种方案是存储在分布式缓存服务器上。基于缓存的分布式session架构如下图所示：
2.2 持久化存储
持久化存储方案有传统的关系型数据库Mysql，也有非关系型的Nosql。
2.2.1 Mysql扩展
主从
在大型分布式系统中，持久化存储一般采用主从架构，以实现主从复制，读写分离。以Mysql为例，一台服务器作为主服务器，一台服务器作为从服务器。前端服务器通过主服务器Master来执行数据写入的操作，数据的更新通过Binary log同步到Slave集群，而对于数据读取的请求，则交由Slave来处理，这样Slave集群可以分担数据库读的压力。
主从复制架构也存在一个问题，即所谓的单点故障。当Master宕机时，系统将无法写入，而在某些特定场景下，也可能需要Master停机，以便进行系统维护升级。为了尽可能降低系统停止写入的时间，最佳的方式就是采用Dual-Master架构，即Master-Master架构。实际上就是两台Mysql互相将对方作为自己的Master，自己作为对方的Slave这样任何一台服务器上的数据变更都会通过Mysql的复制机制同步到另一台服务器。
当然Dual-Master架构并不是为了让两个Master能够同时提供写入服务，这样会导致很多问题，例如MasterA和MasterB几乎同时对一条数据进行了更新，对MasterA的更新比对MasterB的更新早，这样对MasterA上的更新会被同步到MasterB上，老版本的数据将会把版本更新的数据覆盖，并且不会抛出任何异常，从而导致数据不一致的现象发生。在通常情况下，仅仅开启一台Master的写入，另一台Master仅仅作为读库开放，只有当写库宕机或停机维护时才交换双方的角色。
分库分表
对于大型互联网应用来说，数据库单表的记录行数可能达到千万级别甚至是亿级，并且数据库面临这极高的并发访问，采用Master-Slave复制模式的Mysql架构只能够对数据的读进行扩展，而对数据库的写操作还是集中在Master上。
对于访问频繁且数据量巨大的单表来说，首先要做的是减少单表的记录条数，以便减少数据查询所需要的时间，提高数据库的吞吐，这就是所谓的分表。分表能够解决单表数据量过大带来的查询效率下降的问题，但无法给数据库的并发处理能力带来质的提升。此时可以对数据库进行拆分，从而提高数据库写入能力，这就是所谓的分库。分库和分表都可以采用通过一个关键字取模的方式，来对数据访问进行路由。
有时数据库可能即面临着高并发访问的压力，又需要面临海量数据的存储问题，这时需要对数据库既采用分库策略，又采用分表策略，以便同时扩展系统的并发处理能力，提升单表的查询性能，这就是所谓的分库分表。分库分表的策略比单纯的分库或分表的策略更为复杂，一种分库分表的策略如下：
- 记录所在的表全局id=id%(库数量*每个库的表数量)；
- 记录所在的库=取整(记录所在的表全局id/每个库的表数量)；
- 记录所在库的表id=记录所在的表全局id%每个库的表数量。
举个栗子，假设有一张order表，拆分成2个库，每个库4张表，按照上面的路由策略，对于id=10001的记录，应该落在全局的第10001%8=1张表，第1/2=0个库，且是第0个库的第1%2=1张表。
数据分库分表后，虽然查询性能和并发处理能力提高，但也会带来一些问题，如原本跨表的事务上升为分布式事务；由于记录被切分到不同的库与不同的表当中，难以进行多表关联查询，并且不能不指定路由字段对数据进行查询等。
2.2.2 HBase
HBase是一种非关系型的持久化存储系统，是Apache Hadoop项目下的一个子项目，实现了高可靠性、高扩展性、实时读/写的列存储数据库。本质是一张稀疏的大表，用来存储粗粒度的结构化数据。
HBase运行在分布式文件系统HDFS之上，可以搭建大规模结构化存储集群。其数据以表的形式进行组织，每个表由行列组成，与传统关系型数据库不同的是，HBase每个列属于一个特定的列族，通过行和列确定一个存储单元，而每个存储单元又可以有多个版本，通过时间戳来标识，如下图所示：
HBase集群中通常包含两种角色，HMaster和HRegionServer。当表随着记录条数的增加而不断变大后，将会分裂成一个个region，每个region由(startKey,endKey)来标识，包含一个startKey到endKey的半闭合区间。一个HRegionServer可以管理多个Region，并由HMaster来负责HregionServer的调度及集群状态的监管。由于Region可分散并由不同的HRegionServer来管理，因此理论上再大的表都可以通过集群来处理。HBase的集群部署图如下：
与传统的关系型数据库相比，HBase有更好的伸缩能力，更适合于海量数据的存储和处理。而且由于多个Region Server的存在，是的HBase能够多个节点同时写入，显著提高了写入性能。但是HBase本身能够支持的查询维度有限，难以支持复杂查询，如group by、order by、join等，这些特点使得它的应用场景受到了限制。当然，通过第四小节将要介绍的搜索引擎在一定程度上可以解决这些问题。
2.3 消息系统
在分布式系统中，消息作为应用间通信的一种方式，得到了广泛的应用。消息可以被保存在队列中，直到被接受者取出。由于消息发送者不需要同步等待消息接受者的响应，消息的异步接收降低了系统集成的耦合度，提升了分布式系统协作的效率，使得系统能够快响应用户，提供更高的吞吐。当系统处于峰值压力时，分布式消息队列还能够作为缓冲。
2.3.1 ActiveMQ和JMS
ActiveMQ是Apache所提供的一个开源的消息系统，完全采用Java来实现。JMS是一组Java应用程序接口，提供消息的创建、发送、接收、读取等一系列服务。JMS定义了一组公共应用程序接口和相应的语法，类似于Java数据库的统一访问接口JDBC，是一种与厂商无关的API，使得Java程序能够与不同厂商的消息组件很好地进行通信。
JMS支持两种消息发送和接收模型，分别是Point-to-Point和Pub/Sub。点对点模型基于队列(queue)，而发布/订阅模型基于主题(toPic)。
对于点对点消息传输模型来说，多个消息的生产者和消息的消费者都可以注册到同一消息队列，当消息的生产者发动一条消息之后，只有其中一个消息消费者会接收到消息生产者所发送的消息，而不是所有消费者都能收到。
对于发布/订阅消息传输模型来说，消息的发布者需要将消息投递给topic，而消息的订阅者则需要在响应的topic进行注册，以便接收到相应topic的消息。与点对点传输模型不同的是，消息发布者的消息将被自动发送给所有订阅了该topic的消息订阅者。
2.4 垂直化搜索引擎
垂直化搜索引擎在分布式系统中是一个非常重要的角色，它既能够满足用户对于全文检索、模糊匹配的需求，解决数据库like查询效率低下的问题，又能够解决分布式环境下，由于采用分库分表，或者使用NoSql数据库，导致无法进行多表关联或者复杂查询的问题。
–待续。
总结
对这一章内容总结如下：
分布式系统的基础设施有很多，分布式缓存、持久化存储、消息系统和垂直化搜索引擎都是常用的基础组成部分。
分布式缓存主要介绍了memcache和redis，包括memcache使用的分布式策略和Hash算法的选择。
分布式存储解决方案介绍了关系型数据库Mysql，包括Mysql的分库分表。还介绍了文件存储系统HDFS中的HBase。
常用的分布式消息系统有ActiveMQ，Kafka，RabbitMQ等，本章主要通过ActiveMQ来介绍分布式消息系统的使用与集群架构。
垂直化搜索引擎主要介绍了垂直化搜索引擎的基本原理和开源检索工具Lucene，以及基于Lucene的Solr检索工具。