高可用学习与研究

  从大学到工作，感觉最大的成长就是认知上的。

  比如，最初需要考虑的是功能如果实现，怎么把它给实现了。现在要考虑的是如何让服务变得高可用。

  这需要我们开始拓宽自己的技术视野，一个技术，一个中间件不是搭建一下使用一下就完事了，更应该去关注它的高可用。

# # 有多少高可用

  有多少中间件，就有多少高可用。比如缓存中间件redis，就要有redis高可用；比如使用了消息队列，就要有消息队列的高可用。

那为什么不是实现功能就行了呢，因为一旦考虑使用中间件，来帮我们解耦也好，帮我们提升性能也好过，又或者说，使用中间件来解决系统不能解决的问题。

   代码的设计原则中有一个最少知道原则，就像一个秘密，最好是你一个人知道，这样最安全，你只用担心做梦的时候会说出来而已，一旦有第二个人知道，就多了一份风险。同样的道理，系统设计也是，在使用中间件的时候，就已经把秘密告诉了别人，这样维护起来一定是增加了难度。选用中间件的时候，其实也是一种权衡，往往呢，引入中间件，给我们带来的提升更大一点，所以还是会用中间件。那么既然不得不用，那就不得不考虑它的高可用，否则就像一个秘密只有某几个人知道，不能让更多人的人知道一样，一旦有一个人说出去了，就不是秘密了。那么对系统而言，这叫单点故障，如果中间件出了任何问题，将会导致整个系统不可用。所以说是非常严重的。

# # 那么多中间件，那么多高可用，是不是思想应该是一样的呢

  程序的思想并没有那么高大上，普通的就像生活中的小事一样。

  比如你想做一件事，要保证一定要做好它，这件事的时间跨度又比较长。可是人总会生病，总要吃饭。那怎么解决呢，其实每个人都会想到，就是在找一个人和你你起干，在后边看着，你不能干的时候，它立马顶上来。这种就是最早的高可用实现方案，就是副本的概念。

  多副本最早的是 Master/Slave 架构，即简单地用 Slave 去同步 Master 的数据，RocketMQ 最早也是这种实现。分为同步模式（Sync Mode）和异步模式（Async Mode），区别就是 Master 是否等数据同步到 Slave 之后再返回 Client。这两种方式目前在 RocketMQ 社区广泛使用的版本中都有支持，原理图如下图 1 所示。

  你做的事，慢慢做大了了，你一个人忙活不起来了，所以你想开分店。每个店都需要有一个 Master，有一到多个 slaver。

店开多了，老板还是要有的，就理解成 CEO 吧，生活中你是老大，就一直是老大了，但是计算机里边并不是，而是使用选举策略进行选举。没错就像村里选村长一样，少数服从多数。

  说到高可用，通过上边的例子，那就是集群了。集群是能解决一个人干不了的事，但是同样会带来多个人的麻烦。一个人干活没人吵架，两个人干活，你就有可能和另外一个人有分歧的时候，如果一起集群里边有三个人，那你就有可能和两个人有意见分歧的一个道理。

  到底听谁的，如何选举出来一个领导人，以及如何保证消息的互通，就是集群需要解决的最大的问题。

  再一起看一下 zookeeper 实现的 Paxos 算法，就是用来选举的：​​https://www.zhihu.com/question/19787937​​

# # 通过集群来实现高可用

通过集群来做到高可用，就一定绕不开两个问题，一个是选举领导人，一个是消息共享。在上边的文章中应该也看到了DLedger

# # Redis 的高可用方案选择

​​https://yq.aliyun.com/articles/626532​​

# # 高可用的通性问题

~待整理