网关做灰度的时候，要控制流量的比例，比如 3:7 的分发流量到两个不同版本的服务上去。刚开始的想法是每次流量过来生成 100 以内的随机数，随机数落在那个区间就转到那个版本的服务上去，但是发现这样无法较精准的保证 3:7 的比例，因为有可能某段时间内生成的随机数大范围的落在某个区间内，比如请求了 100 次，每次生成的随机数都是大于 30 的，这样 70% 比例的服务就承受了 100% 的流量。
接下来想到了第二种解决方案，能够保证 10（基数） 倍的流量比例正好是 3:7，思路如下：
1、生成 0 - 99 的数组（集合）
2、打乱数组（集合）的顺序，为了防止出现某比例的流量集中出现
3、全局的计数器，要考虑原子性
4、从数组（集合）中取出计数器和 100 取余后位置的值
5、判断取到的值落在那个区间
天气暖和了，19 年的跑步计划已经在心中盘算好久了，本打算昨天生日的时候去开始的，结果天公不作美，一直在下小雨。
关于跑步，一开始为了减肥，现在慢慢喜欢上了这项运动。其实跑步很折磨人，总得有个目标才能坚持下来，或是为了能够在朋友圈炫耀，或是享受跑完步之后的大汗淋漓。
我会下载一个跑步软件，戴上耳机，每完成一公里就会提醒我，我也会心中默默给自己设定个目标，十公里或一个小时，每次跑步过程中我都在和自己较劲，想要放弃的时候心中总会默念，再坚持一下，已经完成了三分之二了，已经完成五分之四了……设了一个目标，总会能够达成，即使过程很艰难，但更喜欢达标后的小小满足感。
有人把生活过成了诗，有人却在彷徨挣扎…
总有一些人能让自己触动心弦，仔细想，也许他们并没有比自己“能耐”多少，或许只是自己已习惯奔波，没有了理想，活在世俗里无法自拔…
我想试着重新生活，找回自己喜欢并且想要成为的那个我，也许吧，这一次我能持之以恒。不再愿意立下各种 flag，不是因为害怕被啪啪打脸，反正都是给自己的。
但是，为什么每次都是想着要改变自己了，真有这么讨厌自己吗？每次都想要改变什么了？给自己制定一套目标，努力克制自己去实现？追寻自己的内心去生活不应该是自己向往的吗，我找不到答案。
提到分布式应用，就不得不考虑分布式事务。在分布式事务中，常见的有 CAP，BASE 理论，解决方案也有很多种，比如：2PC、TCC 、最终一致性等。
2PC（两阶段提交）比较适合单块应用，跨多个库的分布式事务。因为严重依赖于数据库层面来搞定复杂的事务，效率很低，绝对不适合高并发的场景，而且，对于微服务而言，不推荐一个服务出现跨多个数据库操作， 如果需要操作其它数据库数据，推荐通过调用别的服务接口来实现。
TCC 属于强一致性事务的方案，适用资金流转业务相关业务，比如：支付、交易等场景。根据 CAP 理论，这种实现需要牺牲可用性。
如果是一般的分布式事务场景，比如：订单插入之后要调用库存服务更新库存，库存数据没有资金那么的敏感，可以用可靠消息最终一致性方案。
下面是一种可靠消息最终一致性事务方案的实现流程：
通俗的理解，事务是一组原子操作单元。我们希望一些列的操作能够全部正确执行，如果这一组操作中的任意一个步骤发生错误，那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作，要么全都正确执行，要么全都不要执行。
传统的单机应用系统一般使用一个关系型数据库，利用数据库事务来保证数据的一致性，下面先了解一下本地数据库事务的一些特性。
事务从数据库角度说，就是一组 SQL 指令，要么全部执行成功，若因为某个原因其中一条指令执行有错误，则撤销先前执行过的所有指令。
关系型数据库（例如：MySQL、SQL Server、Oracle 等）事务都有以下几个特性：原子性（Atomicity）、一致性（Consistency）、隔离性或独立性（Isolation）和持久性（Durabilily），简称就是 ACID。