0%

网关做灰度的时候,要控制流量的比例,比如 3:7 的分发流量到两个不同版本的服务上去。刚开始的想法是每次流量过来生成 100 以内的随机数,随机数落在那个区间就转到那个版本的服务上去,但是发现这样无法较精准的保证 3:7 的比例,因为有可能某段时间内生成的随机数大范围的落在某个区间内,比如请求了 100 次,每次生成的随机数都是大于 30 的,这样 70% 比例的服务就承受了 100% 的流量。

接下来想到了第二种解决方案,能够保证 10(基数) 倍的流量比例正好是 3:7,思路如下:

1、生成 0 - 99 的数组(集合)
2、打乱数组(集合)的顺序,为了防止出现某比例的流量集中出现
3、全局的计数器,要考虑原子性
4、从数组(集合)中取出计数器和 100 取余后位置的值
5、判断取到的值落在那个区间

阅读全文 »

天气暖和了,19 年的跑步计划已经在心中盘算好久了,本打算昨天生日的时候去开始的,结果天公不作美,一直在下小雨。

关于跑步,一开始为了减肥,现在慢慢喜欢上了这项运动。其实跑步很折磨人,总得有个目标才能坚持下来,或是为了能够在朋友圈炫耀,或是享受跑完步之后的大汗淋漓。

我会下载一个跑步软件,戴上耳机,每完成一公里就会提醒我,我也会心中默默给自己设定个目标,十公里或一个小时,每次跑步过程中我都在和自己较劲,想要放弃的时候心中总会默念,再坚持一下,已经完成了三分之二了,已经完成五分之四了……设了一个目标,总会能够达成,即使过程很艰难,但更喜欢达标后的小小满足感。

有人把生活过成了诗,有人却在彷徨挣扎…

总有一些人能让自己触动心弦,仔细想,也许他们并没有比自己“能耐”多少,或许只是自己已习惯奔波,没有了理想,活在世俗里无法自拔…

我想试着重新生活,找回自己喜欢并且想要成为的那个我,也许吧,这一次我能持之以恒。不再愿意立下各种 flag,不是因为害怕被啪啪打脸,反正都是给自己的。

但是,为什么每次都是想着要改变自己了,真有这么讨厌自己吗?每次都想要改变什么了?给自己制定一套目标,努力克制自己去实现?追寻自己的内心去生活不应该是自己向往的吗,我找不到答案。

提到分布式应用,就不得不考虑分布式事务。在分布式事务中,常见的有 CAPBASE 理论,解决方案也有很多种,比如:2PCTCC 、最终一致性等。

2PC(两阶段提交)比较适合单块应用,跨多个库的分布式事务。因为严重依赖于数据库层面来搞定复杂的事务,效率很低,绝对不适合高并发的场景,而且,对于微服务而言,不推荐一个服务出现跨多个数据库操作, 如果需要操作其它数据库数据,推荐通过调用别的服务接口来实现。

TCC 属于强一致性事务的方案,适用资金流转业务相关业务,比如:支付、交易等场景。根据 CAP 理论,这种实现需要牺牲可用性。

如果是一般的分布式事务场景,比如:订单插入之后要调用库存服务更新库存,库存数据没有资金那么的敏感,可以用可靠消息最终一致性方案。

下面是一种可靠消息最终一致性事务方案的实现流程:

阅读全文 »

通俗的理解,事务是一组原子操作单元。我们希望一些列的操作能够全部正确执行,如果这一组操作中的任意一个步骤发生错误,那么就需要回滚之前已经完成的操作。也就是同一个事务中的所有操作,要么全都正确执行,要么全都不要执行。

传统的单机应用系统一般使用一个关系型数据库,利用数据库事务来保证数据的一致性,下面先了解一下本地数据库事务的一些特性。

一、本地数据库事务

事务从数据库角度说,就是一组 SQL 指令,要么全部执行成功,若因为某个原因其中一条指令执行有错误,则撤销先前执行过的所有指令。

关系型数据库(例如:MySQLSQL ServerOracle 等)事务都有以下几个特性:原子性Atomicity)、一致性Consistency)、隔离性或独立性Isolation和持久性Durabilily),简称就是 ACID

  • 原子性:表示事务执行过程中的任何失败都将导致事务所做的任何修改失效。
  • 一致性:表示当事务执行失败时,所有被该事务影响的数据都应该恢复到事务执行前的状态。
  • 隔离性:表示在事务执行过程中对数据的修改,在事务提交之前对其他事务不可见。
  • 持久性:表示已提交的数据在事务执行失败时,数据的状态都应该正确。
阅读全文 »
Title - Artist
0:00