构建高可用web站点学习（三）

分布式的构建

　　做为网站访问的生命线（数据访问），当然也可以采用分布式的方法来减轻单台服务器的访问压力。之前有讲过Memcached的分布式，但是Memcached服务器互不通信，所以我们也提过redis的主从分布。这篇文章主要的就是关注分布式服务器的一些基本思想。

　　数据库的主从分布：这里我以Mysql为例，当Mysql需要向外扩展的时候的策略则划分为三个部分：复制、拆分以及数据分片 ，而主从分布最主要关注的问题就是主库和从库间的同步。原理如下图：

　　大致描述一下过程：从服务器的IO线程从主服务器获取二进制日志，并在本地保存为中继日志，然后通过SQL线程来在从上执行中继日志中的内容，从而使从库和主库保持一致。主从同步的详细过程如下：

　　1. 主服务器验证连接。

　　2. 主服务器为从服务器开启一个线程。

　　3. 从服务器将主服务器日志的偏移位告诉主服务器。

　　4. 主服务器检查该值是否小于当前二进制日志偏移位。

　　5.  如果小于，则通知从服务器来取数据。

　　6.  从服务器持续从主服务器取数据，直至取完，这时，从服务器线程进入睡眠，主服务器线程同时进入睡眠。

　　7. 当主服务器有更新时，主服务器线程被激活，并将二进制日志推送给从服务器，并通知从服务器线程进入工作状态。

　　8. 从服务器SQL线程执行二进制日志，随后进入睡眠状态。

　　当然，一主库多备库在少量写和大量读时，可以把读分摊到多个备库上。其实这种配置也有很大的用途：

　　1.为不同的角色使用不同的备库。

　　2.把一台备库当作待用的主库，除了复制没有其他数据传输。

　　3.将一台备库放到远程数据中心，用作灾难恢复。

　　4.延迟一个或多个备库，以备灾难恢复。

　　5.使用其中一个备库，作为备份、培训、开发或测试使用服务器。

　　6.创建日志服务器

　　除此之外，Mysql还支持其他的复制拓扑结构，比如说主动-主动模式下的主-主复制；主动-被动模式下的主-主复制（类似于创建一个热备份，但还可以执行读操作，备份，“离线”维护以及升级等）；环形复制；主库、分发主库以及备库（在分发主库上表改为blackhole存储引擎）

　　对于Mysql的扩展问题还可以使用负载均衡等其他手段去解决，这些内容还得再学习一下，以后也会出博客用自己的语言来描述一下。

　　Redis的主从分布：本身也是通过一致性Hash进行分片，优点：Master可以有多个Slave。不会阻塞Master、当一个或多个Slave与Master进行初次同步数据时，Master可以继续处理客户端的请求。相反，Slave在初次同步数据时会阻塞从而不能处理客户端的请求。在Master服务器上禁止数据持久化。

     主从同步一般分两个阶段：第一阶段：Slave服务器主动连接到Master服务器。Slave服务器发送SYNC命令到Master服务器请求同步。Master服务器备份数据库到rdb文件。Master把rdb文件传输给Slave服务器。Slave服务器清空数据库数据，把rdb文件数据导入数据库中。 接下来Master把用 户所有操作，通过命令的形式转发给Slave服务器。

　　MongoDB分片技术：

　　　　看了MongoDB的自动分片：http://blog.fens.me/mongodb-shard/ 之后觉得MongoDB的分片集群也有很多值得学习的地方。

　　　　当满足如下三个条件其中一个，也可以考虑采用分片：

　　　　（一） 数据集大小接近单个节点的存储容量。

　　　　（二） 活跃数据量接近节点最大内存容量。

　　　　（三） 节点的写请求速度无法满足要求。（读请求速度无法满足要求的时候可以通过读写分离的方式或者replicSet模式）

　　　　分片的组件如下：

　　　　　mongos，数据库集群请求的入口，所有的请求都通过mongos进行协调，不需要在应用程序添加一个路由选择器，mongos自己就是一个请求分发中心，它负责把对应的数据请求请求转发到对应的shard服务器上。在生产环境通常有多mongos作为请求的入口，防止其中一个挂掉所有的mongodb请求都没有办法操作。

　　　　　config server，顾名思义为配置服务器，存储所有数据库元信息（路由、分片）的配置。mongos本身没有物理存储分片服务器和数据路由信息，只是缓存在内存里，配置服务器则实际存储这些数据。mongos第一次启动或者关掉重启就会从 config server 加载配置信息，以后如果配置服务器信息变化会通知到所有的 mongos 更新自己的状态，这样 mongos 就能继续准确路由。在生产环境通常有多个 config server 配置服务器，因为它存储了分片路由的元数据，这个可不能丢失！就算挂掉其中一台，只要还有存货， mongodb集群就不会挂掉。

　　　　　shard，这就是传说中的分片了。上面提到一个机器就算能力再大也有天花板，就像军队打仗一样，一个人再厉害喝血瓶也拼不过对方的一个师。俗话说三个臭皮匠顶个诸葛亮，这个时候团队的力量就凸显出来了。在互联网也是这样，一台普通的机器做不了的多台机器来做。

　　小结：对于MongoDB的学习我还是比较少的。毕竟像Mysql研究的书籍和资料很多。本人英文水平也有待加强，尽量去看看官方的文档。学习更多精华。之后会更新有关MongoDB的博客。