分布式系统是“小米加步枪”的集合
2008年阿里发起了去IOE运动，也就是我们说的IBM小型机、Oracle数据库和EMC存储设备。
当时我在工作的时候听到这个消息，想当然的理解为这是因为这些厂商的东西太贵了。
那么随着后来我对分布式系统的逐步理解，除了贵的原因，除了单机性能无法突破摩尔定律的约束。还有一个重要的原因，就是解决了大规模软件系统的开发效率和开发成本的问题。
怎么解决的。
现在我们都知道了，一个大的单体应用是没有办法快速迭代发布的，编译、测试、发布这些动作一气呵成，在庞大的单体环境里面无法做到。分布式系统集结了众多服务节点，就很容易得解决了不同版本，不同功能快速发布的问题。
我们常说微服务的主要目的是为了更快的开发节奏，就是因为微服务也是分布式系统。需要注意的是，反过来，说分布式系统是微服务系统则是不对的。这个问题，你可以自己思考一下。
另外一个，是成本。
分布式系统环境里面，各个服务节点都可以是廉价的PC机，当然不差钱还可以上更好的设备，数据库也可以是开源的MySQL，然后通过网络把它们连接在一起。
说分布式系统是“小米加步枪”的集合，从硬件成本上来说也不为过。
分布式锁最关键的一环是存储
实现一个锁的功能，最根本的必要条件之一是要有一个存储，然后大家都去这个存储这里拿东西，这个时候你用“权利”维护好这个存储：谁能获取，谁不能获取。
这样锁的基本功能就有了。
环境不同，存储的介质也不同。
单进程多线程，用线程可以共享的内存，直接说就是用一个整数。
单机器多进程，用进程可以访问到的共享内存。
多机器多进程，就要考虑额外的一块地方来存储，Redis、etcd等都是可选项。
问题1：一般来说，一个分布式锁服务，它的正确性要求越高，性能可能就会越低。你认为这个说法是对还是错误，可以举个例子吗。
这个说法是正确的。
由于部分失败和异步网络的现实问题，分布式锁是没有办法达到100%正确性。如果要举个例子的话可以对比zookeeper、redis。
高可用选etcd、zk，高性能选Redis。
问题2：什么情况下会发生客户端以为没获取锁，但锁服务已经颁发锁了？若响应超时客户端不会返回error给锁服务让这次获取锁失败吗?
比如，锁服务的逻辑颁发锁成功，但是通过网络到客户端的时候发生丢包，还没有重试的时候，客户端已经超时了，或者是客户端已经收到锁，但是响应发送到锁服务的时候超时了。
对于锁服务来说，它不能区分超时是发生在客户端收到锁之前还是锁之后。
CAP理论是让我们三选二吗
大多数情况下，我们说的可用性，是指的系统的可用性，一致性，是指的数据的一致性。进而，这里的可用性我们又想追求100%，一致性又想追求强一致性。
CAP 理论给我们定义了系统的设计边界，虽然想要设计出超过边界的系统是徒劳的，但是我们却可以无限逼近边界，并且把它作为我们设计系统的目标。
问题3：CAP理论是让我们三选二吗？
说三选二，严格意义上不对，因为这种说法的言外之意，是要放弃第三个。
肯定不是这样。
由于分布式系统所处的网络环境所固有的特性，延迟、丢包等。是的，我们只能保证CP或者AP两个，但是并不意味着我们要放弃第三者，而是要尽量保证第三者。
如果说是三选二的话，言外之意，好像是要放弃一个。这就不对了。
负载均衡的核心是公平性
分布式系统环境下，会有很多个被称为后端服务的服务，客户端向那么多端额后端服务发送请求，到底该往哪里发送，这正是负载均衡要干的事情。
每一个后端服务的机器性能，可能存在差异，性能好的机器是不是要多承受点流量，性能不太好的机器是不是就可以减轻些负担。
是的，负载均衡在保证“雨露均沾”的同时，还要保证服务实例之间的公平性，不能“欺负”性能不好的机器。
怎么做呢。
我们以采用轮询机制的负载均衡来看，轮询是最简单的负载策略了。
这个时候，我们只需要加上权重就可以，彪悍的机器，权重高些。这样，我们就可以利用权重机制来解决服务实例处理性能差异的问题。
来保证负载均衡的公平性。
----END----
这里记录，我每周碰到的，或想到的，引起触动，或感动的，事物的思考及笔记。不见得都对，但开始思考记录总是好的。
