大型分布式网站架构设计与实践 第二章

第二章 分布式系统基础设施

本章介绍和解决的问题：

  1.分布式缓存memcache的使用以及分布式策略，包括Hash算法的选择

2.常见的分布式系统存储解决方案，包括Mysql的分布式扩展、HBash的API及使用场景、Redis的使用等。

3.如何使用分布式消息系统ActiveMQ来降低系统之间的耦合度，以及进行应用间的通信。

4.垂直化的搜索引擎在分布式系统中的使用，包括搜索引擎的基本原理、Lucene详细的使用介绍，以及基于Lucene的开源搜索引擎工具Solr的使用

1.1.1 memcacheAPI的分布式

memcache官方提供Memcached-java-Client工具包含了对memcache协议的java封装。其本身不是一种分布式缓存系统，分布式是由访问他的客户端来实现的，一种简单的实现方式根据缓存的key来进行hash，当后台有N台，访问的服务器为hash（key）%N，即可映射到后台服务器中，会导致一个问题，一旦某台缓存服务器宕机，或者集群压力过大需要新增缓存服务器，大部分的key将会重新分布，对于高并发的系统来说，是一场灾难，所有的请求直接涌向后端的数据库服务器导致“雪崩效应”，

使用consistent Hash算法可以解决上述的问题。consistent Hash原理，自行上网收集，它将hash函数的值域空间组织成一个圆环。

1.2.1 分布式session 

传统的网站存储在cookie中，但是安全性很不高。这时分布式产生，将session统一存储在缓存集群上，如memcache，使用缓存的缺点是，一旦缓存重启，里面的会话也就丢失，需重新建立会话。因为命中的web server可能会宕机，所以session很难在集群间同步，而通过将session以sessionid作为key，保存到后端的缓存集群中中，即便web server宕机，也不会影响其他web server通过sessionid来从缓存服务器中获取session。以Tomcat作为web server ，通过简单的工具memcache-session-manager来实现基于memcache的分布式session（基于sessionid的consistent hash）。

2.2 Mysql扩展

2.2.1 业务拆分

举例：如门户网站，包含了新闻、用户、帖子、评论等几块内容，对于数据库来说，它可能包含这样的几张表，user、news、post、comment，随着当个数据库访问量越来越大，对业务进行拆分，每一块的业务都使用单独的数据库来进行存储。一个数据库拆分为4个数据库。

2.2.2 复制策略（读写分离）

随着访问量的不断增大，拆分后的某个数据库越来越大，到达瓶颈，不得不再次变更，使用Mysql的replication（复制）策略来对系统进行扩展。可以将一台mysql数据库中的数据复制到其他mysql数据库服务器上，当后台数据库取到相同的数据时，通过访问mysql集群中的任意一台服务器，都能访问取到相同的数据。

要实现数据库的复制，需开启Master服务器的Binary log。实际就是Slave从master获取binary log，然后子啊本地镜像的执行日志中记录的操作，因为是异步，可能存在两边的数据延迟。

Master-Slaves复制的架构存在的问题：即所谓的单点故障，当master宕机，或者需要维护、优化、升级，导致整个系统无法写入。

解决：最佳采用Dual-Master架构，即Master-Master架构，就是两台数据库互相作为Master，为了防止数据的重复写入问题，不一致问题，通常会开启一台master的写入，另一台master仅仅stand by或者作为读开放。

2.2.3 分表与分库

对于访问极为频繁且数据量巨大的单表来说，首先要做的就是减少单表的记录数，以便减少数据查询所需要的时间，提高数据库的吞吐，就是所谓的分表。要选择适当的分表策略，使得数据库能够较为均衡低分布到多张表中，并且不影响正常的字段。比如order表记录太多，将被拆分成256张表，拆分的记录根据user_id%256取得对应的表进行存储。至于分库策略与分表类似，有时数据库可能及面临高并发访问的压力，又需要对海量数据的存储问题，这时对数据库即采用分库分表策略，策略如下：

a。中间变量=user_id%(库数量*每个库的表数量)

b。库=取整（中间变量/每个库的表数量）

c。中间变量%每个库的表数量。

如单库单表order拆分成256个库，每个库包含1024个表，那么按照上面的策略，对于user_id=262145的访问，路由的策略计算如下：

中间变量=212145%（256*1024）

库=取整（1/1024）

表=1%1024=1

2.2.4 HBash：是apach Hadoop下的一个子项目，设计实现高可靠性、高可扩展性、实时读/写的列存储在数据库，其本质是一张稀疏的大表来存储粗粒度的结构化数并且能通过简单地增加节点来实现系统的线性扩展。

2.2.4.1 HBase API：其作为分布式数据库，自然提供程序访问的接口

2.2.4.3 rowkey 设计

2.2.5 Redis的使用

redis能够高效率的实现诸如排序取topN、访问计数器、队列系统、数据排重等业务，还能提供高性能的缓存服务，能支持更为丰富的数据类型。

2.2.6 消息系统

2.2.6.1 ActiveMQ & JMS 是apache 提供的开源消息系统，完全采用java，JMS支持两种消息发送和接收模型，一种Point-to-Point（P2P）模型，采用点对点方式发送：基于queue队列。第二种Pub/Sub（Publish/Subscribe即发布/订阅）模型，定义如何向一个内容节点发布和订阅消息，这个内容节点称为topic（主题）可认为是传递的中介。

两者的区别：点对点：当消息发送到queue中，只有其中的一个消息消费者会接收到消息，而不是所有的消费者都会接收到该消息。

发布订阅：消息投递到topic中，消息将被自动发送到所有订阅了该topic的消息订阅者。当订阅者由于某种原因断开了消息发布者的连接时，这段时间内的消息将会丢失， 除非将消息订阅模式设置为持久订阅（durable subscription），这时，当消息订阅者重新连接消息，仍然会获得这部分消息，而不至于丢失这部分消息。

ActiveMQ的集群部署：方案：基于Master-Slave模式实现冷备方案，较为常用的包括基于共享文件系统的Master-Slave架构和基于共享数据库的Master-Slave架构。硬件的性能不能无限制的提升，垂直扩展到一定程度，可以采用broker拆分的方式，将不相关的queue和topic拆分到多个broker，来达到提升系统的吞吐能力的目的。

2.2.7 垂直化搜索引擎 ：既能满足对与全文检索、模糊匹配的需求，解决数据like查询效率底下的问题，又能解决分布式环境下，由于采用分库分表或者使用nosql，导致无法进行多表关联或者进行复杂查询的问题。

2.2.7.1Lucene是apache旗下的一款高性能、可伸缩的开源的信息检索库，构建索引、索引更新与删除、条件查询、结果排序、高亮、中文分词Lucene提供的标准中文分词器StandardAnalyzer只能进行简单的一元分词，以一个子为单元，自带的CJKanalyzer采用的二元分词（常用的中文分词器，IK分词（分词的效果比一元或二元要好的多）、MM分词、以及刨丁分词、imdict分词器）、索引优化（在分布式下，会安排专门的集群来生成索引，并且生成的索引的集群不负责处理前台的查询请求，当索引生成以后，通过索引优化，对索引的段进行合并，合并完之后，将生成好的索引文件分发到提供查询服务的机器供前台应用的查询）、分布式扩展

2.2.8 Solr：是一个基于Lucene的、功能强大的搜索引擎工具，对Lucene进行扩展提供一系列功能强大的HTTP操作接口。