分布式的一些思考?

1、前言

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

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

     简单的说说个人场景，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；

3、分析一波

     前几篇博客一直都是在分析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，毕竟有些特殊状况嘛。

4、结束

    立刻就要年关了，该写篇总结了，给本身指定的不少指标仍是没有完成，还须要多努力，欢迎你们加群438836709，欢迎你们关注我！