密集型应用系统设计(DDIA)
文章平均质量分 69
密集型应用系统设计
JavaEdge.
关注并私信我,获取更多大厂求职经验。《编程严选网》创始人
展开
-
消息传递系统场景
一些消息代理只将消息保存在内存,而另一些消息代理(取决配置)将其写盘,以便在代理崩溃也不丢。一种广泛使用的替代方法:通过消息代理(message broker,也称为消息队列message queue)发送消息,消息代理实质上是一种针对处理消息流而优化的DB。排队结果是,消费者通常异步:当Pro发送消息时,通常只会等待代理确认消息已被缓存,而不等待消息被Con处理。一些协议允许生产者重试失败的消息传递,但当生产者崩溃时,它可能会丢失消息缓冲区及其本应发送的消息,这种方法可能就没用。原创 2022-09-30 23:47:18 · 537 阅读 · 0 评论 -
传递事件流
在流处理的上下文中,记录通常被叫做事件(event) ,本质是一样的:一个小的、自包含的、不可变的对象,包含某时间点发生的某事的细节。一个事件通常包含一个来自日历时钟的时间戳,以指明事件发生的时间。数据库在传统上对这种通知机制支持的并不好,关系型数据库有触发器(trigger),可对变化(如插入表中的一行)反应,但功能有限,且在数据库设计中有些后顾之忧。文件或数据库就足以连接Pro和Con:Pro将其生成的每个事件写入数据存储,且每个Con定期轮询数据存储,检查自上次运行以来新出现的事件。原创 2022-09-30 23:44:30 · 906 阅读 · 0 评论 -
消息代理对比DB
这是关于消息代理的传统观点,它被封装在诸如 JMS 【14】和 AMQP 【15】的标准中,并且被诸如 RabbitMQ、ActiveMQ、HornetQ、Qpid、TIBCO 企业消息服务、IBM MQ、Azure Service Bus 和 Google Cloud Pub/Sub 所实现。有些消息代理甚至可使用 XA 或 JTA 参与两阶段提交协议。原创 2022-09-30 23:48:29 · 504 阅读 · 0 评论 -
消息传递系统-导论
Unix管道和TCP将恰好一个发送者与恰好一个接收者连接,而一个消息传递系统允许多个Pro节点将消息发到同一主题,并允许多个Con节点接收主题的消息。若生产者发送消息的速度>消费者能够处理的速度,一般有三种选择:系统丢掉消息,将消息放入缓冲队列,或使用背压(backpressure,也称流量控制flow control:阻塞生产者,以免其发送更多的消息)。如对周期传输的传感器读数和指标,偶尔丢失的数据点可能并不重要,因为更新的值会在短时间内发出。:Pro发送包含事件的消息,然后将消息推给Con。原创 2022-09-30 23:45:57 · 695 阅读 · 0 评论 -
为什么会有流处理?
因此,批处理程序必须将数据人为分成固定时间段的数据块,如每天结束时处理一天的数据或每h结束时处理一小时的数据。但这有很大的假设:输入有界,即已知和有限的大小,所以批处理知道它何时能完成输入的读取。批处理的问题是,输入的变更只会在一天之后的输出中反映,对急躁的用户来说太慢。为减少延迟,可更频繁运行处理,如每s的末尾或更连续一些,完全抛开固定时间切片,当事件发生时就立即处理,这就是流处理(stream processing)的想法。” ,研究连续处理这些流的方法和工具,以及它们用于应用构建的方式。原创 2022-09-30 23:41:27 · 677 阅读 · 0 评论 -
多主复制下处理写冲突(1)-同步与异步冲突检测及避免冲突
多主复制最大问题可能发生写冲突,必须解决之。如两个用户同时编辑wiki,如图-7。用户1将页面标题从A-》B,且用户2同时将标题从A-》C。每个用户的更改都成功提交到本地主节点。但当异步复制到对方时,发现存在冲突。正常的主从复制则不会出现此问题。......原创 2022-07-31 15:16:02 · 432 阅读 · 0 评论 -
并发性,时间和相对性(1)-确定前后关系
若两个操作同时发生,则称为并发,但事实上,操作是否在时间上重叠并不重要。由于分布式系统复杂的时钟同步问题,现实中很难严格判断两个事件是否同时发生。为更好定义并发性,并不依赖确切发生时间,即若两个操作并不需要意识到对方,就能说它们是并发操作,而不管它们发生的物理时间。计算机系统中,即使光速快到允许一个操作影响另一个操作,但两个操作也可能并发。如网络拥塞或中断,可能就会出现两个操作由于网络问题导致一个操作无法感知另一个,因此二者成为并发。...原创 2022-07-31 16:09:25 · 640 阅读 · 0 评论 -
系统架构设计(3)-可扩展性
即使系统现在可靠,不代表将来一定可靠。发生退化的最常见原因是负载增加:并发用户从最初的10,000 增长到 100,000或系统目前处理数据量超出之前很多倍。可扩展性,描述系统应对负载增加的能力。它不是衡量一个系统的一维指标, 谈论“系统X是可扩展 ”或“不扩展”无太大意义。相反,讨论可扩展性通常得考虑:“若系统以某种方式增长,应对措施有啥”, “该如何添加计算资源来处理额外的负载”先得简洁描述系统当前的负载,才能更好讨论后续的增长问题(例如负载加倍,意味啥?)。负载可以用称为负载参数的若干数字来描述。参数原创 2022-06-03 22:21:41 · 3782 阅读 · 3 评论 -
数据系统分区设计 - 分区再平衡(rebalancing)
随业务井喷,DB出现变化:所有这些更改都要求数据、请求可以从一个节点转移到另一个节点。 将负载从集群中的一个节点向另一个节点移动的过程称为 再平衡(rebalancing)。无论哪种分区策略,分区rebalancing通常至少要满足:图-3提过,最好将hash值分成不同区间范围,然后每个区间分配给一个分区。那为何不使用mod(Java中的%运算符)。如 返回介于 0 和 9 之间的数字。若有 10 个节点,编号为 0~9,这似乎是将每个K分配给一个节点的最简单方法。但问题是,若节点数量 N 变化,大多数K将原创 2022-07-13 00:22:54 · 951 阅读 · 0 评论 -
复制延迟案例(3)-单调读
单调读取仅意味着若一个用户顺序多次读取,则不会看到时间后退,即若先前读取到较新的数据,后续读取不会得到更旧数据。实现单调读取的一种方案确保每个用户总从同一副本读取(不同用户可读不同副本)。但若该副本失败,用户的查询将需重新路由到另一个副本。第一个查询返回最近由用户1234添加的评论,但第二个查询不返回任何东西,因为滞后的从节点还没有拉取写入的内容。若用户刷新网页,而每个请求被路由到一个随机的服务器,这种情况是很有可能的。前面异步复制读异常的第二个案例,出现用户数据向后回滚的怪状。...原创 2022-07-31 14:57:01 · 284 阅读 · 0 评论 -
复制延迟案例(1)-最终一致性
若应用正好从一个异步的从节点读取时,而该从节点落后于主节点,它可能会看到过期数据,导致数据库中不一致由于并非所有写入都反映在从节点,若同时对主、从节点发起相同查询,可能得到不同结果。正常操作中,主节点和从节点上完成写操作之间的时间延迟(复制滞后)可能不足1s,这样的滞后,在实践中通常不会导致太大影响。这种可伸缩结构下,只需添加更多从节点,就能提高读请求的服务吞吐量。读多写少场景,这是不错的选择创建多个从节点,将读请求分散到所有的从节点,从而减轻主节点的负载,并允许向最近的副本发送读请求。...原创 2022-07-31 14:52:37 · 328 阅读 · 0 评论 -
多主复制下处理写冲突(4)-多主复制拓扑
复制的拓扑结构描述了写请求从一个节点传播到另一个节点的通信路径。若有两个主节点,如图-7,只有一个合理拓扑结构M1必须把他所有的写同步到M2,反之亦然。当有两个以上M,各种不同拓扑都可能的。如图-8说明了一些例子。最普遍的拓扑是全部到全部,即图-8©,每个M将其写入同步到其他所有M。但也会使用更多受限制的拓扑例如,MySQL仅支持环形拓扑(circulartopology),其中每个节点接收来自前一个节点的写入,并将这些写入(加上自己的写入)转发给后序节点。另一流行结构是星形形状。...原创 2022-07-31 15:19:09 · 326 阅读 · 0 评论 -
系统设计之图状数据模型
多对多关系是不同数据模型之间的重要区别特征。若数据大多是一对多(树结构数据)或记录之间无关系,则文档模型最合适。但若多对多关系的数据很常见,关系模型能处理简单的多对多,但随数据之间关联复杂度增加,将数据建模转化为图模型更自然。图的组成:很多数据能建模为图。典型案例:社交网络顶点是人,边指示哪些人彼此认识Web图顶点是网页,边表示与其他页面的HTML链接公路或铁路网顶点是交叉路口,边表示他们之间的公路或铁路线很多著名算法可在这些图上运行。如汽车导航系统搜索道路网中任意两点之间最短路径, PageRank计算W原创 2022-06-11 23:39:40 · 748 阅读 · 0 评论 -
最后写入胜利(丢弃并发写入)
实现最终收敛的一种方案,每个副本总存储最新值,允许覆盖并抛弃旧值。假定每个写请求都最终同步到所有副本,只要确定哪个写入是最新,则副本就能最终收敛到相同值。但如何定义最新?图-12中,当客户端向数据库节点发送写入请求时,客户端都不知道另一个客户端,因此不清楚哪个先发生。争辩哪个先发生其实没有大意义,我们说支持写入并发,也就意味着它们的顺序不确定。即使无法确定写请求的“自然顺序”,我们也能强制任意排序。如为每个写请求附加一个时间戳,然后选择最新即最大的时间戳,丢弃较早时间戳的写入。...原创 2022-07-31 16:06:42 · 666 阅读 · 0 评论 -
无主复制系统(3)-Quorum一致性的局限性
若有n个副本,且配置w和r,使得w+r>n,期望可以读到一个最新值。因为成功写入的节点集合和读取的节点集合必有重合,这样读取的节点中至少有一个具有最新值,如图-11。一般设定r和w为简单多数(超过n/2)节点,即可确保w+r>n,且同时容忍多达n/2个节点故障。但是,法定人数不一定必须是大多数,只是读写使用的节点交集至少需要包括一个节点。其他法定人数的配置是可能的,这使得分布式算法的设计有一定的灵活性。您也可以将w和r设置为较小的数字,以使w+r≤n(即法定条件不满足)......原创 2022-07-31 16:03:28 · 423 阅读 · 0 评论 -
多主复制的适用场景(1)-多IDC
对主从复制模型进行扩展,则可配置多个主节点,每个主节点都能处理写,后面复制的流程类似处理写的每个【主节点】都必须将该数据更改转发到所有其他节点。主从复制下,若M所在IDC故障,必须切换至另一个IDC,将其中的1个从节点提升为M。尽管多主复制有这些优势,但也有一个很大的缺点两个不同IDC可能会同时修改相同的数据,写冲突必须解决(图-6中conflictresolution)。若DB还采用分区,不同分区可能将主副本放在不同节点,但对给定的某分区,则只有一个主节点。...原创 2022-07-31 15:10:46 · 499 阅读 · 0 评论 -
数据复制系统设计(2)-同步复制与异步复制
复制的重要可选项同步复制,synchronously异步复制,asynchronously关系型DB中,这通常是个可配置项,而其他系统通常是硬性指定或只能二选一。图-2显示了系统各模块间通信情况。请求或响应标记为粗箭头。从节点2接收复制日志前存在一段长延迟。复制一般速度很快,大多DB系统能在1s内完成所有从节点更新。但并不保证复制耗时多久。有时,从节点可能落后主节点几min或更久,如从节点正在故障恢复或系统已接近最大设计上限或节点间存在的网络问题。同步复制的优点。......原创 2022-07-30 23:53:23 · 825 阅读 · 0 评论 -
无主复制系统(1)-节点故障时写DB概述
单主、多主复制思路都是客户端向一个主节点发写请求,而DB系统负责将写请求复制到其他副本。主节点决定写顺序,从节点按相同顺序应用主节点发送的写日志。某些数据存储系统采用不同设计放弃主节点,允许任何副本直接接受客户端的写。最早的复制数据系统就是无主节点的(或称之为去中心复制、无中心复制),但后来在关系数据库主导时代,这个想法几乎被忘却。在亚马逊将其用于其内部的Dynamo系统后,它再一次成为流行的DB架构。......原创 2022-07-31 15:22:26 · 605 阅读 · 0 评论 -
数据系统分区设计 - 请求路由
现已将数据集分布多个节点,但当客户端要发送请求时,如何知道应该连接哪个节点?若分区再平衡,分区和节点的映射也随之变化。对此,需要有一段逻辑知晓这些变化并负责客户端的连接:如若我想读/写K “foo”,需连接哪个IP地址和端口号?这其实就是服务发现,任何通过网络访问的系统都有此问题,特别是当其目标高可用(在多台机器上有冗余配置)。该问题有多种方案,如图-7:不管啥方案,关键问题:作出路由决策的组件(可能是某个节点,路由层或客户端)如何知道分区和节点之间的对应关系及变化?这是个有挑战的问题,所有参与者都要达成共原创 2022-07-13 00:24:02 · 310 阅读 · 0 评论 -
复制延迟案例(2)-读己之写
许多应用让用户提交一些数据,然后查看提交的内容。如客户DB中的记录或某主题的评论。提交新数据必须发送到主节点,但当用户读数据时,可能从【从节点】读取。这对读密集和偶尔写入的负载很合适。但异步复制则有问题,如图-3若用户在写后马上查看数据,则新数据可能尚未到达副本。对用户而言,看起来好像是刚提交的数据丢了,用户会不高兴。此时,需“写后读一致性(read-after-writeconsistency)”,也称读写一致性(read-your-writesconsistency)。该机制保证。...原创 2022-07-31 14:54:57 · 324 阅读 · 0 评论 -
多主复制下处理写冲突(3)-收敛至一致的状态及自定义冲突解决逻辑
有些冲突显而易见,如图-7的两个写操作并发修改同一条记录中的同一字段,并设为两个不同值。其他类型的冲突可能就微妙了。如会议室预订系统,记录谁订了哪个时间段的哪个房间。应用需确保每个房间只有一组人同时预定(不得有相同房间的重复预订)。此时,若同时为同一房间创建两个不同预订,就冲突了。尽管应用在预订时会检查房间可用性,但若两次预订由两个不同主节点进行,则还是可能冲突。......原创 2022-07-31 15:17:49 · 323 阅读 · 0 评论 -
数据分区设计(0)-前言
每条数据(或每条记录,每行或每个文档)属于且仅属于某特定分区。每个分区都能视为一个完整小型数据库,虽然数据库可能存在跨分区操作。原创 2022-08-28 20:42:15 · 344 阅读 · 0 评论 -
系统设计之分区策略
对大数据集或非常高吞吐量,仅复制还不够,还需将数据拆分成为分区(partitions),也称分片(sharding)1。每条数据(或每条记录,每行或每个文档)属于且仅属于某特定分区。每个分区都能视为一个完整小型数据库,虽然数据库可能存在跨分区操作。提高可扩展性。不同分区可放在一个无共享集群的不同节点。这样的一个大数据集可分散在更多磁盘,查询负载也随之分布到更多处理器。单分区查询时,每个节点对自己所在分区查询可独立执行查询操作,添加更多节点就能提高查询吞吐量。大型复杂查询尽管比较困难,但也可能做到跨节点的并行原创 2022-07-10 22:51:16 · 855 阅读 · 1 评论 -
多主复制的适用场景(2)-需离线操作的客户端和协作编辑
架构上,这种设置类似IDC之间的多主复制,只不过每个设备都是个“IDC”,而它们之间的网络连接极不可靠。此时,每个设备都有一个充当M的本地DB(接受写请求),并在所有设备之间采用异步方式同步这些多M上的副本,同步滞后可能是几h或数天,具体时间取决于设备何时再联网。当一个用户编辑文档时,所做更改将立即应用到本地副本(Web浏览器或客户端应用程序中的文档状态),并异步复制到服务器和编辑同一文档的任何其他用户。离线状态下进行的任何更改,会在设备下次上线时,与服务器和其他设备同步。应用在断网后仍需继续工作。...原创 2022-07-31 15:12:35 · 290 阅读 · 0 评论 -
数据系统分区设计 - 分区与二级索引
目前的分区方案都依赖KV数据模型。KV模型简单,都是通过K访问记录,自然可根据K确定分区,并将读写请求路由到负责该K的分区。但若涉及二级索引,就很复杂。二级索引通常并不能唯一标识一条记录,而是一种加速特定值的查询,如查询用户JavaEdge的所有操作,查找包含词语 的所有博客等。许多KV存储(如HBase)为了减少实现复杂度而放弃二级索引,但一些(如 Riak)已开始支持它们,二级索引也是 Solr 和 ES 等搜索服务器的根本。二级索引的主要挑战是不能整齐地映射到分区。有两种方案支持对二级索引进行分区:原创 2022-07-13 00:20:44 · 401 阅读 · 0 评论 -
复制延迟案例(4)-一致前缀读
该案例违反因果律。想象先生和夫人之间的对话MrMrs,你能看到多远未来?Mrs通常约10s,Mr.这两句之间有因果关系夫人听到先生的问题并回答该问题。想象第三者老王在通过从节点听对话。夫人说的内容是从一个延迟很低的从节点读取,但先生所说的内容,从节点的延迟要大的多,如图-5,于是该观察者会听到Mrs通常约十秒钟,MrMrMrs,你能看到多远未来?对观察者来说,看起来好像夫人在先生发问前就回答了问题。防止这种异常,需要新类型的保证。...原创 2022-07-31 14:58:08 · 268 阅读 · 0 评论 -
无主复制系统(2)-读写quorum
若有n副本,写入须w个节点确认,至少为每个读取查询r个节点。只要w+r>n,我们期望在读取时获得最新值,因为r个读取中至少有一个节点最新。节点不可用原因因执行操作的错误(由于磁盘已满而无法写),因为节点关闭(崩溃,关闭电源),由于客户端和服务器节点之间的网络中断等。成功的写操作要求三副本中至少两个完成,即至多有一个副本可能包含旧值。集群中可能存在多于n的节点。(集群的机器数可能多于副本数目),但任何给定的值只能存储在n个节点上。Dynamo风格的数据库中,参数n,w和r一般可配置。.........原创 2022-07-31 16:02:10 · 427 阅读 · 0 评论 -
无主复制系统(2)-读修复和反熵
复制模型应确保所有数据最终复制到所有副本。在一个失效节点重新上线后,它如何赶上错过的写入呢?原创 2022-08-28 19:54:45 · 359 阅读 · 0 评论 -
分布式复制系统设计-总结
若某领导者失败,且你提升了一个异步更新的追随者成为新的领导者,则最近提交的数据可能丢失。出现故障节点,网络中断和延迟峰值时,多领导者、无领导者复制更稳健,但以更难推理并仅提供非常弱的一致性保证为代价。最后讨论多领导者、无领导者复制固有并发问题:因为他们允许多个写并发,这可能冲突。所有客户端将写都发到单主节点,该节点将数据更改事件发送到其他副本(从节点)。客户端发送每个写到几个节点,并从多个节点并行读取,以检测和纠正具有陈旧数据的节点。这里甚至不考虑更隐蔽的失效场景,如由于bug导致的无提示的数据损坏。原创 2022-08-21 13:26:39 · 687 阅读 · 2 评论 -
并发性,时间和相对性(2)
设想人们也可以从他们的购物车删除商品,此时把并发值都合并起来可能会导致错误结果:若合并了两个客户端的值,且其中有一个商品被某客户端删掉,则被删除的项目会再次出现在合并的最终值中。在图-14中,两个客户端最后的值是[牛奶,面粉,鸡蛋,熏肉]和[鸡蛋,牛奶,火腿]。合并最终值应该是[牛奶,面粉,鸡蛋,培根,火腿],其中去掉了重复值。与图-13版本号一样,当读数据时,版本向量会从数据库副本发送到客户端,随后写入值时需将版本信息包含在请求中一起发送回数据库。版本向量可确保从某副本读取,随后写入到另一个副本。原创 2022-08-21 13:09:58 · 467 阅读 · 0 评论 -
数据复制系统设计(3)-配置新的从节点及故障切换过程详解
选出新主节点后,若原主节点重新上线并加入集群,新主节点在此期间可能收到冲突的写请求,因为原主节点未意识到角色变化,还会尝试同步其他从节点,但其中的一个现在已接管成为新任主节点了。因此,从节点可以连接到主节点,并请求在从节点断开连接时发生的所有数据变更。建的行,但因新主节点计数器落后于原主节点(即二者并非完全同步),它重新使用已被原主节点分配出去的某些主键,而这些主键恰好已被外部Redis所使用,导致MySQL和Redis之间数据不一致,最后一些私有数据被错误地泄露给其他用户。......原创 2022-07-31 14:27:41 · 446 阅读 · 0 评论 -
分布式系统的一致性与共识(1)-综述
分布式系统中的许多事情可能出错,最简单方法是让整个服务失效,并向用户显示错误消息。若无法接受,就得找到容错方法即使某些内部组件出现故障,服务也能正常运行。本文讨论构建容错分布式系统的算法和协议的一些案例。假设所有问题都可能发生网络中的数据包可能会丢失、重新排序、重复推送或任意延迟;时钟只是尽其所能近似;节点可以暂停(如GC)或随时崩溃。构建容错系统的最好方法,是找到一些带有实用保证的通用抽象,实现一次,然后让应用依赖这些保证。和事务处理方法相同。...原创 2022-07-30 23:49:06 · 352 阅读 · 0 评论 -
多数据中心操作和检测并发写入
Cassandra在其默认配置的无主模型都支持跨数据中心操作副本的数量n包括所有数据中心的节点,在配置中,您可以指定每个数据中心中您想拥有的副本的数量。无论数据中心如何,每个来自客户端的写入都会发送到所有副本,但客户端通常只等待来自其本地数据中心内的法定节点的确认,从而不会受到跨数据中心链路延迟和中断的影响。数据库集群之间的跨数据中心复制在后台异步发生,其风格类似于多领导者复制。若节点每当接收到新的写请求就简单覆盖原有K,则节点将永久不一致,如图-12,节点2认为X最终值B,而其他节点认为值是A。...原创 2022-07-31 16:05:17 · 470 阅读 · 0 评论 -
精通Java事务编程(3)-弱隔离级别之快照隔离和可重复读
表面看,RC已满足事务所需的一切特征支持中止(原子性),防止读取不完整的事务结果,并防止并发写的混乱。这点很关键!为我们的开发省去一大堆麻烦。但此隔离级别仍有很多地方可能产生并发错误。如图-6说明RC可能发生的问题。Alice在银行有1000存款,分为两个账户,每个500。现有一笔转账交易从账户1转移100到账户2。若她在提交转账请求后、银行DB系统执行转账的过程中间,查看两个账户的余额,她可能看到账号2在收到转账前的余额(500),和账户1在完成转账之后的余额(400)。这词有些滥用。...原创 2022-07-24 17:58:29 · 358 阅读 · 0 评论 -
精通Java事务编程(4)-弱隔离级别之防止更新丢失
RC和快照隔离级别主要都是为解决只读事务遇到并发写时可以看到什么(虽然中间也涉及脏写),还没触及另一种情况两个写事务并发,而脏写只是写并发的特例。写事务并发带来最着名的问题就是丢失更新,如图-1的两个并发计数器增量为例。应用从DB读一些值,修改它并写回修改后的值,则可能导致丢失更新。若两事务同时执行,则其中一个的修改可能丢失,因为第二个写内容并未包括第一个事务的修改(有时会说后面的写入这是一个普遍的问题,所以已经开发了各种解决方案。...原创 2022-07-24 17:59:50 · 338 阅读 · 0 评论 -
精通Java事务编程(7)-可串行化隔离级别之两阶段锁定(2PL,two-phase locking)
近30年,DB只有一种广泛使用的串行化算法两阶段加锁。原创 2022-07-24 18:08:02 · 472 阅读 · 0 评论 -
精通Java事务编程(1)-深入理解事务
为实现高可靠,系统必须处理这些问题。但完善容错机制工作量巨大,要仔细考虑所有可能出错的事情,并充分测试。十年来,事务一直是简化这些问题的首选机制。事务将应用程序的多个读、写操作组合成一个逻辑单元。即事务中的读、写操作是个执行的整体整个事务要么成功(提交),要么失败(中止或回滚)。若失败,程序可安全地重试。如此,便无需再担心部分失败的情况,应用层的错误处理就简单很多。也许你觉得事务就这么简单了,但细究起来也许不止于此。事务不是先天存在的;它是为简化应用层的编程模型而人为创造的。...原创 2022-07-24 17:53:34 · 488 阅读 · 0 评论 -
精通Java事务编程(2)-弱隔离级别之已提交读
若两个事务不触及相同数据,即无数据依赖关系,则它们能安全并行运行。才会出现并发问题。并发BUG很难通过测试找到,因为这样的错误只有在特殊时序下才会触发。这样的时序问题可能非常少发生,通常很难重现。并发性也很难推理,特别是在大型应用中,你不一定知道哪些其他代码正在访问DB。只有一个用户访问数据时,应用开发就够麻烦了,多用户并发更困难,每个数据都可能被多个用户修改。因此,DB一直试图通过【事务隔离】来隐藏内部的各种并发问题。理论上,隔离是假装没有并发发生,让程序员生活不再加班。...原创 2022-07-24 17:57:00 · 295 阅读 · 0 评论 -
精通Java事务编程(8)-可串行化隔离级别之可串行化的快照隔离
串行化的隔离级别和高性能就是相互矛盾的吗?也许不是,一个称为可串行化快照隔离(SSI,serializablesnapshotisolation)算法很有前途。提供完整的可串行化保证,而性能与快照隔离相比只有很小性能损失。SSI在2008年首次被提出,如今既用于单节点DB(PostgreSQL9.1后的可串行化)和分布式DB(FoundationDB)。由于SSI与其他并发控制机制相比还很年轻,还在实践中证明自己。...原创 2022-07-24 18:09:28 · 548 阅读 · 0 评论 -
精通Java事务编程(5)-写倾斜与幻读
这种异常称为写倾斜,不是脏写,也不是丢失更新,这俩事务更新的是两个不同对象(Alice和Bob各自值班记录)。这里发生的冲突不是那么明显,但很显然确实是竞争状态若两个事务串行,则第二个医生就不能歇班。异常行为只有在事务并发时才可能。可将写倾斜视为广义的丢失更新。不同事务可能更新不同对象,则可能发生写倾斜而若更新同一对象,则可能脏写或丢失更新我们有很多方法防止丢失更新。由于涉及多对象,单对象的原子操作无效基于快照隔离来实现自动检测丢失更新也有问题。......原创 2022-07-24 18:01:24 · 698 阅读 · 1 评论