首页 | 新闻 | 新品 | 文库 | 方案 | 视频 | 下载 | 商城 | 开发板 | 数据中心 | 座谈新版 | 培训 | 工具 | 博客 | 论坛 | 百科 | GEC | 活动 | 主题月 | 电子展
返回列表 回复 发帖

分布式系统常见的事务处理机制(1)

分布式系统常见的事务处理机制(1)

CAP 定理CAP 定理(也称为 Brewer 定理),是由计算机科学家 Eric Brewer 提出的,即在分布式计算机系统不可能同时提供以下全部三个保证:
  • 一致性(Consistency):所有节点同一时间看到是相同的数据;
  • 可用性(Availability):不管是否成功,确保每一个请求都能接收到响应;
  • 分区容错性(Partition tolerance):系统任意分区后,在网络故障时,仍能操作
显然,为了保障性能和可靠性,我们将数据复制多份,分布到多个节点上,同时也带来了一个难点,那就是如何保持各个副本数据的一致性。换句话说,我们选择了 AP ,则必须要牺牲掉 C 了。
但是,在实际的应用场景中,数据的一致性往往也是需要保证的。那么这是否违背了 CAP 定理呢?
一致性模型其实,数据的一致性也分几种情况,大致可以分为:
  • Weak 弱一致性:当你写入一个新值后,读操作在数据副本上可能读出来,也可能读不出来。比如:某些存储系统,搜索引擎,实时游戏,语音聊天等,这些数据本文对完整性要求不高,数据是否一致关系也不大。
  • Eventually 最终一致性:当你写入一个新值后,并不一定能马上读出来,但在某个时间窗口之后保证最终能读出来。比如:DNS,电子邮件,消息中间件等系统,大部分分布式系统技术都采用这类模式。
  • Strong 强一致性:新的数据一旦写入,在任意副本任意时刻都能读到新值。比如:文件系统,RDBMS都是强一致性的。
也就是说,在设计分布式系统时,我们并不一定要求是强一致性的,根据应用场景可以选择弱一致性或者是最终一致性。
事务的作用事务有如下作用:
  • 保证执行结果的正确性
  • 保证数据的一致性
  • ACID
常见的事务处理机制Master-Slave 复制Slave 一般是 Master 的备份。在这样的系统中,一般是如下设计的:
  • 读写请求都由 Master 负责。
  • 写请求写到 Master 上后,由 Master 同步到 Slave 上。
这种机制的特点是:
  • 数据同步通常是异步的
  • 有良好的吞吐量,低延迟 * 在大多数 RDBMS 中支持,比如 MySQL二进制日志
  • 弱/最终一致性
这种机制的缺点是,如果 Master 挂了,Slave 只能提供读服务,而没有写服务。
Master-Master 多主复制指一个系统存在两个或多个Master,每个Master都提供读写服务。这个机制是Master-Slave的加强版,数据间同步一般是通过Master间的异步完成,所以是最终一致性。 Master-Master的好处是,一台Master挂了,别的Master可以正常做读写服务,他和Master-Slave一样,当数据没有被复制到别的Master上时,数据会丢失。很多数据库都支持Master-Master的Replication的机制。
这种机制的特点是:
  • 异步
  • 最终的一致性
  • 多个节点间需要序列化协议
返回列表