数据库大牛李海翔详解全局读一致性技术

作者简介:李海翔,网名“那海蓝蓝”,腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术:事务管理和并发访问控制》、《数据库查询优化器的艺术:原理解析与SQL性能优化》、《大数据管理》,广受好评。

2019年5月8日,腾讯数据库TDSQL技术专家李海翔为中国数据库技术大会DTCC带来了腾讯最新的数据库核心技术:TDSQL原创的全局读一致性技术。

李海翔在会议现场

腾讯专家工程师李海翔在DTCC上做了主题为“腾讯TDSQL全局读一致性”的技术内容分享。本次分享,基于数据库事务处理的核心技术并发访问控制技术和分布式系统CAP理论中的一致性,TDSQL原创性提出了全面地解决读一致性的算法,是的,分布式事务的一致性和分布式系统的一致性统一在一起。

如下是本次分享的主要内容,从如下八个角度全面分享了全局一致性的前世今生、光辉未来。

  1. 数据库的事务处理技术,解决了什么问题?
  2. 分布式事务型数据库,出现了什么新问题?–读半已提交数据异常
  3. 业界是怎么解决读半已提交数据异常问题的?
  4. 分布式事务型数据库,解决了读半已提交数据异常,就一劳永逸了吗?
  5. TDSQL的事务处理模型
  6. 什么是全局一致性?
  7. TDSQL是怎么解决各种数据异常的?
  8. 展望未来

一 、数据库的事务处理技术,解决了什么问题?

数据库是一个高并发系统,所有的操作,通过事务的语义加以约束。而事务的语义,表现为事务的四个特性,ACID。而一个数据库系统,其最核心的技术,就是事务处理技术,为了保障ACID,数据库使用了多种复杂技术,其中,核心技术的核心是并发访问控制算法。

事务处理技术,有两个初衷:一是数据正确性,二是并发高效率。

数据库的操作,把SQL语句的语义简化后,只有读操作和写操作两种。并发操作,就是读写操作的并发,组合后分为四种:读读、读写、写读、写写。其中,读写、写读、写写三种会产生多种“数据异常现象”。常见的数据异常如图1,发生了这些数据异常,就不能保证上述的数据准确性。

图1 事务型数据库系统的常见数据异常

这么多数据异常(图1列出11种),会带来什么问题呢?其表现,是在数据项上,出现了逻辑上不应该出现的“不一致性”现象。说不一致,抽象难理解,看不出其危害,所以我们用“脏读数据异常”举个简单例子:

一个骗子T2转帐1000元给事务T1,事务T1检查自己的账户,入账了1000元,然后事务T1把一件衣服卖给了骗子T2,之后骗子T2拿到衣服后回滚了转账1000元的操作,然后逃之夭夭了。事务T1既没有拿到钱还丢失了衣服,损失很大。所以要避免这样的异常发生。

所以,数据库的事务处理机制,就是要避免商业交易(并发的交互行为)出现各种使交易任何一方受损的事情发生。

于是,事务型数据库提出了多种并发访问控制算法(如图2)和其他相关技术,确保商业交易正常。用数据库的术语讲,就是确保ACID四个特性。图2中的多种算法,在单机事务隔离级别的可串行化隔离级别,能够确保图1中的各种数据异常不会发生。(小问题,请思考:分布式事务型数据库中的并发访问控制算法,能否确保图1中的各种数据异常不会发生呢?)

图2 事务型数据库的常见并发访问控制算法

二  、分布式事务型数据库,出现了什么新问题?–读半已提交数据异常

在金融支付等业务场景中,对账业务,是支付体系中最重要的一环,也是保证交易、资金安全的最后一道防线。涉及金融的业务,一定要对账。

使用数据库做对账,如图3,有两个物理的节点,Na和Nb分别有两个账户X和Y(X和Y也代表账户余额),现在第一个写事务,要从X账户向Y账户转账10元,当此写事务在Na节点完成提交,但Nb节点尚没有提交(如网络延迟发生、或Nb节点负载重尚没有能执行事务的提交操作)。此时,另外一个分布式事务读事务要做对账操作,其在Na节点读到了已经提交的“X-10”的值,而在Nb节点读到的是“Y”(未提交的不能读),则总账为“X-10+Y”,这个就是数据不一致,因为总账目少了10元钱。数据库系统据不能容忍这种事情发生。

图3 分布式事务型数据库的读半已提交数据异常

对于任何一个分布式事务型数据库,如果基于封锁并发访问机制实现并发事务的可串行化调度,是不会存在这里所讨论的问题的。其原因在于:一旦Na节点写完毕数据,则表明Nb节点至少在Y账户这个数据项上施加了写锁,而新的对账读事务是不能读取Y数据项的值的,其只能等待,因此不会发生对账不平的问题。腾讯TDSQL就是这样的,换句话说,没有实现可串行化的数据库,大概率会存在读半已提交数据异常(小问题,请思考:为什么这里说大概率呢?答案参见图4中的2次读算法)。

但是,如果纯粹使用封锁并发访问控制机制实现可串行化,事务处理的并发度降低,分布式数据库的事务处理吞吐量就会底,这违背了事务处理技术的另外一个初衷:高效。所以类似TDSQL的分布式数据库,用户通常不使用可串行化隔离级别,原因就在于想要使得数据库高效。而如OceanBase、Oracle等数据库,干脆没有实现可串行化隔离级别,而是直接把出现数据异常的危险抛给了用户

现在,我们再来讨论一下,TDSQL会不会出现“读半已提交数据异常”?

TDSQL除了支持可串行化隔离级别外,还支持可重复读(RR)、读已提交(RC),但这2个隔离级别,同另外一种并发访问控制算法、MVCC技术紧密绑定,绑定的原因,是为了提高并发度,使得读写、写读操作互不影响。就是在MVCC机制下,TDSQL出现了“读半已提交数据异常”,为什么呢?

因为前述“在Nb节点读到的是“Y”(未提交的不能读)”就是Y的旧版本,而不是未提交的新版本,这是MVCC机制决定的(小问题,请思考:是不是所有使用MVCC技术的,都得小心是不是存在“读半已提交数据异常”啦?是哈,得小心+小心。要不然,账目不平可就解释不清楚了)。

三 、业界是怎么解决读半已提交数据异常问题的?

其实,业界目前没有特别好的解决方式。如图4,典型的解法如下5类:

第一种:全局事务管理器架构。典型的例子如PostgreSQL-XC,其存在一个全局的事务处理节点,用于解决整个分布式系统分为内的所有事务冲突,这样需要把各个子节点的事务相关信息都发送给全局唯一的事务处理节点,不光通信量大,而且存在单点瓶颈,限制了事务的处理能力。

第二种:TDSQL以封锁机制实现全局可串行化。前述已经分析过,不再赘述。

第三种:物理时钟,全序排序事务降低并发度。典型的例子如著名的Spanner。Spanner彻底地解决了所有数据异常,这是通过实现所有以事务为单位的事件全序排序来完成的。换句话说,实现了线性一致性和事务的可串行化隔离。但是,Spanner以Truetime机制全序排序事务的方式,降低了并发度,导致其分布式事务的吞吐量很低,效率甚至低于基于封锁的并发访问控制下的可串行化实现(即:以线性一致性串起了事务一致性,所以理论上看,Spanner每秒数百个的事务的吞吐量使得效率低到了极限)。

第四种:混合时间戳机制,实习局部偏序排序。典型的例子如仿Spanner的CockroachDB,通过SSI实现了可串行化解决了事务类型的数据异常,但是不能解决全局读一致性的问题(需要全局排序才能解决全局读一致性问题,但混合时钟机制做不到全局有序)。另外,如果选择非可串行化隔离级别,则和Spanner一样,还是可能会出现“读半已提交数据异常”。

第五种:特定的解决机制–两次读机制。2次读机制,源自学术界《Scalable atomic visibility with ramp transactions》这篇paper。其核心思想,是在Na和Nb节点第一次分别读到“X-10”和“Y”这两个版本后,通过特定算法识别这两个数据不是出于一个一致的点,所以重新去Nb节点再读一次,这时,因为一段时间过去了,Nb节点大概率完成提交,读到的数据很可能是“Y+10”,因而可以保持对账不出现差错(X-10+Y+10=X+Y,账目保持平衡)。但是,两次读延迟了事务的执行,降低了整个事务的吞吐量;更重要的是,这种解决问题的方式,只针对“读半已提交数据异常” (小问题,请思考:如果有新的数据异常,还需要读2次数据吗?)。

图4 数据库界对“读半已提交数据异常”主流的解法

四 、分布式事务型数据库,解决了读半已提交数据异常,就一劳永逸了吗?

如标题所言,分布式事务型数据库,解决了如图1和图3提及的各种数据异常之后,是不是就完美了呢?答案是否定的。

一波未平一波又起。

很不幸,图5有给出了新的数据异常。在《Distributed snapshot isolation: global transactions pay globally, local transactions pay locally》这篇Paper中,称之为“Cross数据异常”。

图5列出两类分布式系统下的数据异常,,其中第一类本质上就是“读半已提交数据异常”,而第二种“Cross数据异常”,其发生的背景,依然可以放到金融对账的业务背景中来理解。请看图5右子图部分,有两个物理节点,分别执行了本地事务和分布式事务。事务s和t是本地事务,修改了不同的数据项;事务x和事务y是两个分布式事务,都在读取数据;两个分布式数据读取数据被本地事务影响,读到了不一致的数据,事务x读到的是(a0,b1),事务y读到的是(b0,a1),而数据的一致状态要么是(a0,b0)要么是(a1,b1)。从业务的角度看,事务x和事务y都发起对账,结果对出来的结果不仅不同而且还是一个临时状态对应的结果,这就是数据异常,对账业务不能容忍此类事情发生。

数据库内核层,解决这样的数据异常,通常的方式,是通过建立事务之间的读写依赖关系图,从中看是否有环存在,如果有则表明数据异常出现,因而需要打破环,即回滚其中某个事务,避免问题出现(小问题,请思考:会不会还有新的数据异常呢?数据异常如果也层出不穷该怎么办?)。

图5 新的数据异常—Cross异常图

五 、TDSQL的事务处理模型

先来分享一下TDSQL的事务处理框架,这个框架,可以用图2来做大的知识背景。

首先,TDSQL第一代的事务处理模型,采取了图2中的基于封锁的并发访问控制协议和MVCC并发访问控制协议,混合解决并发冲突问题。所以图6中给出的SS2PL整体就是封锁的并发访问控制协议,然后用2PC技术来实现提交阶段的原子写操作。这是整体架构。

在具体实现冲突解决的时候,需要结合MVCC和隔离级别,来解决各种数据异常。这就要区分写写冲突、读写冲突和写读冲突三种具体的情况。

写写冲突,通常依靠封锁机制。原理较为简单,不再赘述。

读写冲突和写读冲突,则借助MVCC来避免锁造成的延迟事务执行的问题,使得后者能继续继续,提高了并发度,所以主流的数据库基本上都实现了MVCC机制。

图6 TDSQL第一代分布式事务处理架构图

其次,TDSQL第二代的事务处理模型,新支持了图7基于OCC(乐观并发访问控制技术)和DTS(动态调整时间戳的并发访问控制技术)的技术,使得TDSQL的分布式事务处理能力产生了质的飞跃(OCC使得并发度提高,DTS使得并发访问控制算法去中心化),分布式事务处理性能提升数倍,并减少了对中心化时间戳节点的依赖,在分布式事务处理的去中心化的道路上,迈出一大步。

图7 TDSQL第二代分布式事务处理架构图

六 、什么是全局一致性?

还记得标题四中的小问题不?小问题,请思考:会不会还有新的数据异常呢?数据异常如果也层出不穷该怎么办?

现在,我们正面来谈谈,什么是全局读一致。目的就是一劳永逸的解决各种数据异常。

在单机数据库时代,数据库理论中有个“可串行化”技术,对应到了隔离级别中的可串行化隔离级别,因为理论上把所有事务都排序,消除了并发,因而不会再有数据异常产生。

但是,在分布式数据库时代,为了提高效率不想使用全局事务管理器限制并发,就采用了去中心化的架构设计分布式数据库;不想使用有额外成本的原子钟等,但又得解决各种数据异常,因此“可串行化”就不够用了(“可串行化”的本质就是在排序)。

再加上,分布式系统,存在各种不确定性,如网络发生分区、瞬间闪断、延时等,使得发生在分布式系统内的读和写事件反序(与发生的顺序相反)到达某个节点,这就又为分布式数据库识别事件之间的先后逻辑关系带来困难。为了规避这些问题带来的“逻辑认识上的困扰”,分布式系统中提出各种“一致性”,如线性一致性、因果一致性、单调写、写后读等各种问题(这些问题参见图8左子图)。

因此,分布式事务型数据库其核心要解决的问题就是:同时满足2个一致。一是分布式读一致性,二是分布式事务一致性。我们把这两种一致性,称为“全局一致性”(注意不是全局读一致性哦)。

分布式读一致性(即全局读一致性),从外部用户的视角,观察数据库内部发生的事件产生的结果之间的顺序要与事件发生的实际顺序保持一致,不能A事件先于B事件发生,但先不到B事件的结果后才可能看到A事件的影响。这意味着,需要对实际发生的事件进行排序。

而对于分布式事务型数据库,是从数据库内核层的角度,保证并发的事务之间,能造成数据异常的情况(读写依赖关系图形成了环)下部分事务被回滚或阻止其发生。及确保事务的可串行化。

如上两者都被保证的情况下,数据异常可被杜绝。Spanner就是从分布式读一致性中的线性一致性出发,约束了事务使之串行提交而保证无数据异常的,这好比用一根竹签先后串起了两种一致性需求(但效率因事务提交需要等待而低下),确保所有的事件全序排序杜绝任何异常。

但是,正式提出一个问题:大问题,请思考:有没有高效的方式确保全局一致性?

答案是:有。请看下一节,TDSQL的解决技术。

注意本文的概念变化:标题是全局读一致性,这是引子;但到本节发展成为了全局一致性;概念的变迁,有其内在的因素,请多体会哦。

图8 全局一致性图

七 、TDSQL是怎么解决各种数据异常的?

让我们回顾一下TDSQL的发展史,TDSQL2017年推出分布式事务处理技术,2018年推出全时态数据库系统。在全时态数据库技术中,提出一个“全态数据可见性判断算法”。

这个算法,初衷意在解决“分布式事务型数据库中,全态数据在任何时间点上怎么能够读到一致的数据”这样的问题(算法参考腾迅论文《Efficient time-interval data extraction in MVCC-based RDBMS》)。但是,以这个算法为基础,还可以做到全局一致性。更多技术,请参考VLDB 2019,腾讯论文《A Lightweight and Efficient Temporal Database Management System in TDSQL》。

如图9左上子图所示:

  1. 初始时刻t0:r11、r21、r31三个初始的数据项分布式在不同的物理节点上,此时这三个数据项处于一个“一致的”状态。
  2. t1时刻:r11被修改为r12,此时之后,r12、r21、r31三个数据项处于一个“一致的”状态;虚线表示了他们处于一致状态。
  3. t2时刻:r21、r31同时被同一个事务修改,分别变为了r22、r32,所以事务提交后,r12、r22、r32这三个数据项处于一个“一致的”状态。
  4. 其他时刻依次类推。
  5. 不支持全时态的数据库,只有当前态,所以DML类操作,只读取最新数据即可。
  6. 支持了全时态的数据库,需要从历史上任何一个点出发,找出这个出发点对应的处于一致性状态的数据。所以怎么标识哪些数据的所有值(当前值、历史值)和事务之间的关系,是全时态数据库当初解决的一个问题。
  7. 现在,有了如上这个基础,做到全局一致性,就容易了很多。所用技术如图9右子图部分。
    1. 写写冲突封锁机制互斥:对于前面我们提到的写写冲突,还是依靠封锁机制解决,避免丢失更新等数据异常发生。
    2. MVCC从新版本到旧版本:基于MVCC,可以使得读写和写读冲突并发执行,提高了事务处理的效率,不然数据库系统性能一塌糊涂不可使用。另外,使用MVCC,读区版本的顺序是有讲究的,从最新版本开始读就要求构造版本链的时候版本由新到旧。
    3. 局部节点处于Prepared状态:在MVCC背景下,修改可见性判断算法,当数据在2PC阶段所有节点同意提交后,正常情况下事务就一定能够提交(系统故障发生后可被恢复),这时,数据即对满足快照的事务可见。
    4. 全局事务Committed状态:设立全局事务提交状态,当协调器在2PC阶段所有节点同意提交后,即可设置事务状态的全局标志为Committed(注意不是Prepared),然后通知子节点设置各自状态为Prepared的。只有全局提交标志为Committed,事务读取到的数据才是合法数据,可参考如图8中的左下子图部分,表示了分布式父子事务之间状态导致可见性的关系。如上2点,避免了前述的读半已提交数据异常。
    5. 异步、批量设置本地事务状态:协调器上全局事务状态信息,异步地发给涉及的各个子节点,完成子节点上原子事务状态的Committed化。这点是性能优化的问题。
    6. 全局逻辑时钟(非跨城/洲分布):使用全局逻辑时钟,为事务建立全局一致的快照,即用SI技术(快照技术),确保全局读一致性。
    7. 冲突可串行化:协调器同时判断是否存在冲突环,以解决Cross类型的数据异常。(小问题,请思考:还有没有别的办法解决cross异常?)
  8. 如此,TDSQL实现了全局一致性,即达到了外部强一致性和事务一致性的统一。这里介绍了主干流程,为了提高效率,TDSQL又做了很多优化点,以提高事务的吞吐量。

图9 TDSQL全时态数据库的核心技术—全态数据可见性判断算法

但是,再次正式提出一个问题:大问题,请思考:有没有更高效的方式确保全局一致性?

八 、展望未来,为什么TDSQL在事务处理技术上是领先的?

TDSQL一直走在探索分布式事务处理的道路上,走过的路充满挑战(图10)。团队同时享受到了战胜挑战带来的“不可言而此处无声胜有声的与我心有戚戚焉”乐趣。

前进的途中,TDSQL携手中国人民大学教育部数据工程和知识工程重点实验室,采用动态时间戳解决事务冲突并去中心化全局时间戳依赖、用data-drive技术减少事务冲突、用细粒度减少事务冲突等,实现分布式事务处理能力,提升TDSQL分布式事务处理的效率。期待有机会就这些技术进行分享。

图10 TDSQL分布式事务、分布式一致性处理技术展望

特别感谢中国人民大学教育部数据工程和知识工程重点实验室,与腾讯TDSQL携手,共同研发了本文分享的技术。

Image placeholder
binzhao88
未设置
  16人点赞

没有讨论,发表一下自己的看法吧

推荐文章
如何保证缓存与数据库的双写一致性?

分布式缓存是现在很多分布式应用中必不可少的组件,但是用到了分布式缓存,就可能会涉及到缓存与数据库双存储双写,你只要是双写,就一定会有数据一致性的问题,那么你如何解决一致性问题?CacheAsidePa

阿里面试题:如何保证缓存与数据库的双写一致性?

作者:你是我的海啸出处:https://blog.csdn.net/chang384915878/article/details/86756463只要用缓存,就可能会涉及到缓存与数据库双存储双写,你只

写数据库同时发mq消息事务一致性的一种解决方案

一、引子《事务注解(@Transactional)引起的数据覆盖故障》一文收到不少反馈。事务里不要有rpc,基本原则,sb封装的太好了,把很多人养傻了,function级别的事务,坑太大。网友一这个是

如何构建批流一体数据融合平台的一致性语义保证?

一、批流一体架构 批和流是数据融合的两种应用形态 下图来自Flink官网。传统的数据融合通常基于批模式。在批的模式下,我们会通过一些周期性运行的ETLJOB,将数据从关系型数据库、文件存储向下游的目标

MySQL是怎么保证数据一致性的

在《写数据库同时发mq消息事务一致性的一种解决方案》一文的方案中把分布式事务巧妙转成了数据库事务。我们都知道关系型数据库事务能保证数据一致性,那数据库到底是怎么设计事务这一特性的呢?一、MySQL事务

一致性哈希算法 PHP 实现

一致性哈希算法(consistenthashing)PHP实现本文转载于 一致性哈希算法在1997年由麻省理工学院提出的一种分布式哈希(DHT)实现算法,设计目标是为了解决因特网中的热点(Hotspo

陆天炜: GoldenDB事务一致性处理机制优化历程

前言:GoldenDB是中兴通讯推出的一款自研的金融级交易型分布式数据。针对金融行业关注的数据库事务一致性问题,中兴通讯GoldenDB分布式数据库架构师陆天炜,在DTCC2019数据库大会上做了干货

从 GFS 失败的架构设计来看一致性的重要性

作者简介陈东明,饿了么北京技术中心架构组负责人,负责饿了么的产品线架构设计以及饿了么基础架构研发工作。曾任百度架构师,负责百度即时通讯产品的架构设计。具有丰富的大规模系统构建和基础架构的研发经验,善于

Talos网卡负载优化:基于个性化一致性哈希的负载均衡

本文将详细介绍基于个性化一致性哈希的流量均衡方法。 目录  业务增长带来的流量均衡需求基于一致性哈希的调度策略个性化一致性哈希的负载均衡流量均衡在Talos中的实现前文《小米消息队列的实践》介绍了小米

Redis学习笔记2—缓存、集群、一致性等

缓存淘汰策略为了保证高性能,缓存都保存在内存中,当内存满了之后,需要通过适当的策略淘汰老数据,以便腾出空间存储新数据。数据的淘汰策略,典型的包括FIFO(先进先出,淘汰最老数据),LRU(淘汰最近最少

再读一次Vue官方文档带来的意外惊喜

前言Vue目前算是我用的时间最长的一个框架了,但是最近总是在想,我真的了解Vue了吗,还是说,仅仅只是会用它而已了呢.最开始用Vue的时候只是草草看了一遍文档,细节之处并未关心,以至于后面项目中遇到很

技术大牛创业失败,原来是缺少这套思考框架

2016年以前,大众媒体对技术人创业的报道可以总结为一句话:“为何技术人创业更容易成功?”,2018年后,这个总结变成了“一个程序员创业的血泪史”。这样的转变令人哭笑不得。最近几年,技术创业者多到让

巨杉TechDay回顾 | 与携程、巨杉、知乎大牛一起探寻DT时代数据库架构之道

数据,已成众多企业的核心资产。如今企业越来越懂得数据的重要性,也愈发清楚数据将为公司带来的巨大价值。在物联网、AI等技术的普及下,数据井喷仍在持续进行,如何更好地管理和使用这些“无穷无尽”的数据,则成

借力中国数据库技术大会 达梦DM8数据库新品正式发布

5月8日—10日,第十届中国数据库技术大会(DTCC2019)如约而至。本届大会以“数据风云,十年变迁”为主题,设定2大主会场及21个技术专场,邀请了来自国内外互联网、金融、教育等行业百余位技术专家,

Oracle数据库不同损坏级别的恢复详解

墨墨导读:在DBA的日常工作中不可避免存在着数据库的损坏,本文将主要介绍Oracle数据库遇到不同损坏级别下的应该采用的恢复方法,供读者在遇到此类情景时,能的找到适合自己的恢复方法,提高工作效率。数据

腾讯基于全时态数据库技术的数据闪回

作者简介:李海翔,网名“那海蓝蓝”,腾讯金融云数据库技术专家。中国人民大学信息学院工程硕士企业导师。著有《数据库事务处理的艺术:事务管理和并发访问控制》、《数据库查询优化器的艺术:原理解析与SQL性能

大数据是个技术,数据库才是它最好的产品形态

星环科技(以下简称:星环)的定位是大数据基础软件公司,而非数据库公司,却在数据库方面,做的比很多数据库公司更好更猛?这是为何?“我们认为,大数据是个技术,数据库才是它最好的产品形态”,星环科技研发总监

Oracle ADW业务数据平台点亮DTCC2019数据库技术大会!

数字大脑、互联网+、智能+、人工智能、边缘计算……信息技术领域好像从不缺少概念,但无论世界如何变化,数据是一切业务的核心。要想有效管理、分析和挖掘数据带来的价值,数据库一定是必需品。2019年5月8日

学习猿地又签约一名大牛讲师

学习猿地根据IT方向的线上学习特点,研发人机互动教学系统,打造领先的学习模式。平台签约了十名大牛联合创办,每个合伙人再召集几名身边的技术大咖,根据程序员的岗位需求研发精品课程,并将一门学科中所需要的全

BAT大牛推荐开发人员必备Spring源码剖析文档,深度剖析Spring

为什么学习读源码我们每天都和代码打交道。经过数年的基础教育和职业培训,大部分程序员都会「写」代码,或者至少会抄代码和改代码。但是,会读代码的并不在多数,会读代码又真正读懂一些大项目的源码的,少之又少。

《MySQL主从不一致情形与解决方法》

一、MySQL主从不同步情况1.1网络的延迟由于mysql主从复制是基于binlog的一种异步复制通过网络传送binlog文件,理所当然网络延迟是主从不同步的绝大多数的原因,特别是跨机房的数据同步出现

干货 | 揭秘京东数科强一致、高性能的分布式事务中间件JDTX

导读:在分布式数据库、云原生数据库、NewSQL等名词在数据库领域层出不穷的当今,变革——在这个相对稳定的领域已愈加不可避免。相比于完全革新,渐进式增强的方案在拥有厚重沉淀的行业则更受青睐。同所有分布

这波技术社区的程序员,技术视野有点堪忧!

前一段时间写了一篇文章《凌晨1点突发致命生产事故,人工多线程来破局!》,只是一篇生产事故的记实文章,没想到在圈内流传甚广,其中有程序员对其中的细节有点疑惑,刚好国庆可以和大家再进一步探讨一下。现在技术

冬虫夏草之技术路线图之一【“技”——技术篇】

作为一名28年证券机构从业经历的老兵,杨松一直在观察和研究IT技术对金融机构的业务重构,以及证券业务变革相关的内容。今天,让我们来看看这位金融业内人士如何利用他28年的行业积累,通过“技”“术”“路”

“我是技术总监,你干嘛总问我技术细节?”

题图:fromZoommy每个周末的午后,把儿子送进EF读书,随后找个环境幽静的咖啡馆坐一会,这便是我一周中最放松的时光。在咖啡厅的气氛和环境这两点上,我似乎有强迫症,比如装修主色调的运用,地上装饰是