分布式缓存中多机房分布策略

​       目前的互联网架构中，缓存已经成了一个不可或缺的部分，可以将没有了缓存，很多事情玩不转了，目前开源中用的比较多的例如memcached，也有公司自己研发缓存系统的，例如淘宝已经开源的tair，当缓存的服务器数量增加或者本身就需要多机房容灾的时候，数据在多机房情况下如何分配，就成了一个问题，这篇文章就对这个问题展开讨论。

       对于分布式缓存来讲，由一个集群机器组成，这些机器有个特点，就是内存很牛逼，没办法，做缓存就是要放在内存里的吗，不过也有内存服务器的硬板来缓冲的，把内存文件dump到硬盘，用于机器断电等情况。虽然由一个集群（也就是多台机器）组成，但是对于应用系统来讲，他们就是一个机器，一个提供缓存的机器。

       应用系统在请求缓存的时候，可能只需要简单的通过缓存机器的列表，然后发送请求即可，缓冲机器自动去hash等操作，这些对于应用系统而言是透明的。

       目前有哪些分布策略呢？简单列举几个，有些是在工作中遇见的，有些是自己YY的，但是也基本靠谱。

    ​    ​机器分布在单个机房，单份数据

    ​    ​优点貌似只有方便管理了，物理机器就在一个机房，如果应用机器在多个机器，那就有可能存在跨机房调用了。如果这个放机器的机房出现问题，那机房本身是没有办法容灾的。

    ​    ​机器分布多个机房，一份数据，对外部而言，就是一个集群

    ​    ​这种的分布，机器可能对等的分布在多个机房，存储一份数据，虽然物理的部署上是分开的，但是在逻辑上，外部就是认为他是一个集群，如果应用系统也同样分布在多个机房，那就会存在跨机房调用的情况，扩机房有啥问题？不同机房的调用网络延迟会比较大。但是一般机房之间的调用是很快的。这样部署非常适合缓存类的数据，且对于跨机房调用没有那么敏感的情况下。这种情况下，如果一个机房down机了，那这个机器对应的数据会丢失，但是问题不大，因为是缓存数据，可以继续从持久化的系统里面去加载进来。由于是单份数据，也就没有一致性的问题了。

    ​    ​机器分布在多个机房，一个机房一份数据，对外部而言，每个机房就相当于一个独立的集群

    ​    ​这种分布，有个最大的好处，就是应用服务器和缓存机器如果在同一个机房，那网络延迟会很小的，机房的调用策略可以配置，就是例如应用服务器所在的机房仅仅能够调用这个机房的缓存机器。但是由于各个机房的数据时独立的，也就是独立集群，数据一致性存在问题，如果应用系统更新数据，是需要同步更新到各个集群的，这个时候，各个独立集群数据一致如何保证呢？目前已知的解决办法是增加一个独立的集群（暂且叫做A-Server）去做这个事情，更新的请求发送到这里，这个集群负责同步数据到各个数据集群，从而来保证一致性。

    ​    ​两个机房，互为主备，两份数据，经典的主备模式

    ​    ​主备模式是大家常常见到得了，正常情况下主集群来提供服务，主集群搞一个异步的线程来同步数据到备集群，当主集群挂掉的情况下，应用系统自动切换请求道备集群。这种是能够保证数据一致性的，目前很多DB也是采用这样。最常见的就是mysql的master-slaver模式，如果读写请求的比例差距很大的事情，例如读请求很大，可以增加多台slaver来挡一些读的请求。这种模式下，数据的安全性会比较高。

    ​    ​机器分布在多个机房，多份数据，对外部而言，整体就是一个集群

    ​    ​一个集群内的数据时一份，但是多个集群就多份数据，整体对外部就是一个集群，而非一个一个的独立集群，这样有个好处就是可以让应用服务器选择本地机房优先的策略来做事情。

    ​    ​当然在实际的处理中，可能还有有，如何选择呢？根据业务场景去选择，这年头还是场景为王的年代啊，不能生搬硬套。