分布式的一些思考? 分布式问题

一、前言

最近系统上遇到一些问题，我又仔细去思考了一下CAP相关方面的东西，有点感悟想写篇文章，来好好思索下CAP这个东西;

二、先聊聊一聊我遇到的问题?

简单的说说我的场景，MQ推送消息过来以后写入redis，然后多个进程去消费redis中的数据，最后处理完成进入ES。最近更改一些需求，要求必须是只能生成一条明细，我们系统可能推送多次，我们通过缓存是可以判断出最早的一条，但是系统上线以后还是会出现多条，后来经过排查发现原来是MQ时序问题，导致最终生成2条明细，后来我采用使用唯一ID处理这个问题，中间还思考通过ES版本号处理的这种方式，最终还是采用唯一Id处理，这里我们不比较这两种方式好坏。还是要关注我们说主题分布式的思考，我只想通过我这例子来说说CAP到底是处理什么问题的?

上图基本就是我们处理数据的流程，我省去了很多东西，比如分布式锁、缓存呀等等这些东西。我们单纯就借助这个模型来说说分布式的问题，A、B、C代表进程，我们都是分开部署多个节点在不同的机器上，类似于很多单体Web程序部署多台机器上通过Nginx分发处理请求，我们这些也都可以算是分布式系统，我们只是单纯自己玩，不相互联系而已，以一个不恰当的比喻来说最熟悉的陌生人。那CAP是处理什么问题的，大家可以看下这篇文章，看不懂可以翻译下，当然我就是属于看不懂的，哈哈。摘录下其中比较重要的话，翻译过来以后是:

在一个分布式系统(指互相连接并共享数据的节点的集合)中，在读/写操作的时候，一致性(Consistence)、可用性(Availability)、分区容错性(Partition Tolerance)只能同时保证其中两者，比如我们上面说两种情况，虽然分布式有读写操作，但是系统之间没有共享数据和相互连接，所以我们可以保证这3者同时存在。这里我们思考一个场景来解释下什么是共享数据和相互连接，就拿我们经常使用的淘宝买东西来说吧，当你买一件东西的时候，需要查看你的余额，然后发生扣款，打入到第三方账户种，这里你的钱就是共享数据和相互连接，明白这两个概念我们就来解释解释CAP的概念。

一致性(Consistence):其实就是类似于事务的隔离性，客户端不会读取到正在提交的事务，只有提交成功以后才客户端才可以查询到变更的信息，举个形象一点的例子来说，淘宝在你下单成功以后才会扣你的钱，不会下单失败了扣你的钱，在你下单的过程中你的账户里面的钱是不会动的，这就是一致性;

可用性(Availability)：非故障的节点在合理的时间内返回合理的响应(不是错误和超时的响应)，这个我感觉不需要举例子吧，就是系统的每个功能都能正常的返回结果;

分区容错性(Partition Tolerance)：当发生网络分区后，系统依然能够发挥原来的作用，举个例子就是当ES某个节点挂掉的时候我们依然可以正常使用，这个例子可能不是恰当，但是能说明分区容错性的重要性，后面我们再来讨论下ES的CAP设计，这还是一件蛮有意思的事情;

在了解这3者之间的关系时候，我们就来思考下为什么只能三选二?在分布式系统中，必须要多台机器部署才能叫做分布式，多台机器相互联系的时候可能会发生网络或者其他一些故障，我们在设计的时候必须考虑到P，这个时候我们就该考虑C和A为什么不能共存，这二者本就是矛和盾的存在，当发生分区故障的时候，为了保证C，系统必须禁止写入，当有写入的请求的时候，系统就会返回错误，这个时候就和A冲突掉了，A要求的是不能是错误和超时响应，所以这就分布式系统理论上不能够选着CA，只能够选择CP和AP;

三、分析一波

前几篇博客一直都是在分析ES，那我们就来分析分析ES中CAP应用，大家可以提出不同的意见，支持辩驳。之前ES系列文章中也讲过ES会有脑裂的现象，这就是ES在P上的设计，这个不是我们讨论的重点，我们重点是ES到底是CP还是AP?可以在这几方面的进行讨论，读，写去解释下ES对于A和C的设计。

读

在ES读取数据的时候有preference这个类型，默认情况下操作在可用的分片中随机读取，我们可以通过设置参数来控制只读主，不懂这个大家可以参考下官方文档,做一点深层次思考preference的设计就是A和C的权衡，当我们系统要求很高的一致性性的时候我们就可以只读主分片，当要求不高的时候我们就可以随机读取，具体大家使用可以根据自己系统进行选择;

写

在之前的系列中也讲过ES的translog(事务日志)机制和flush机制，其实这里面的设计也是ES对C和A的选择，只是权力交给了我们，大家具体可以参考官方文档，这里我们也做下介绍，

TransLog

index.translog.durability：如果设为 async，默认情况下，ES 会每隔五秒对 TransLog 执行一次 fsync 和 commit 的操作;如果设为 request(default)，则在每次真正执行index、delete、update 或者 bulk index 操作前立刻将 TransLog fsync 到每一个主分片和副本分片中，并返回成功;

index.translog.sync_interval:设置为async时，每次持久化间隔的时间;

还有上面我们讲述的ES锁的控制，有乐观和悲观锁，乐观锁是通过版本控制也就是我们常用的最终一致，悲观锁是强一致，设计方面的东西就理解到这里，其实我认为ES跟偏向于AP的设计，毕竟如果对这些不是很了解的话，他都是默认高可用，其实某些情况下还是不要过多执着于这个系统到底是CP还是AP，毕竟有些特殊情况嘛。