数据一致性

今天在开发补货管理模块时，要新增加一个接口，功能是可以修改补货管理表里的订单状态。 在数据库里，由一个orderStatus字段来表示订单的当前状态，而这个状态可以由两种用户角色进行修改。一个是加工厂，另一个是供应商。之前在写方法的时候，还没体会到数据一致性的问题。但是昨天由老欧写了一个接口给我看了之后，发现比我写的方法多用到了表里的lastModifiedOn和modifiedBy字段。来校验数据。心里有些疑惑，就让他给我讲讲这方面的东西。 他说：A在修改状态的时候，从前端获取到的状态是1，要将其修改成3.但是在这个过程中，B用户已经把状态修改成2了，那么，A获取到的状态1，就成为脏数据。： 脏数据在临时更新（脏读）中产生。事务A更新了某个数据项X，但是由于某种原因，事务A出现了问题，于是要把A回滚。但是在回滚之前，另一个事务B读取了数据项X的值(A更新后)，A回滚了事务，数据项恢复了原值。事务B读取的就是数据项X的就是一个“临时”的值，就是脏数据。 在项目里：整个业务流程由spo.tpl spo.controller.php spo.SCA.php spo.model.php 组成。 tpl显示数据，controller组织数据，SCA发布接口，model实现接口。A用户在修改tpl上显示的数据的时候，一起取到了<input type="hidden" value="{

在分布式系统中著有 CAP 理论，该理论由加州大学伯克利分校的 Eric Brewer 教授提出，阐述了在一个分布式系统中不可能同时满足 一致性（Consistency） 、 可用性（Availability） ，以及 分区容错性（Partition tolerance） 。 C：一致性 在分布式系统中数据往往存在多个副本，一致性描述的是这些副本中的数据在内容和组织上的一致。 A：可用性 可用性描述了系统对用户的服务能力，所谓可用是指在用户容忍的时间范围内返回用户期望的结果。 P：分区容错性 分布式系统通常由多个节点构成，由于网络是不可靠的，所以存在分布式集群中的节点因为网络通信故障导致被孤立成一个个小集群的可能性，即网络分区，分区容错性要求在出现网络分区时系统仍然能够对外提供一致性的可用服务。 对于一个分布式系统而言，我们要始终假设网络是不可靠的，因此分区容错性是对一个分布式系统最基本的要求，我们的切入点更多的是尝试在可用性和一致性之间寻找一个平衡点，但这也并非要求我们在系统设计时一直建立在网络出现分区的场景之上，然后对一致性和可用性在选择时非此即彼。实际上 Eric Brewer 在 2012 年就曾指出 CAP 理论证明不能同时满足一致性、可用性，以及分区容错性的观点在实际系统设计指导上存在一定的误导性 。传统对于 CAP 理论的理解认为在设计分布式系统时必须满足 P，然后在

0 分布式集群的数据一致性 分布式集群的存储层一般由缓存层与数据固化层构成。 对存储层进行读写的时候，需要考虑到数据的一致性。数据一致性分为强一致（实时一致性）和弱一致(最终一致性)，根据数据一致性要求的不同，读写流程也要做相应的改变。下面结合个人经验给出两种情况下的读写流程步骤。 一般的简单的分布式系统，缓存层可以使用redis集群，固化层则可以使用mysql或者mongodb集群。 限于个人经验，本文所指的缓存层专指redis集群，固化层专指mysql或者mongodb集群。 下面所有函数都遵循的几个条件： 1 数据的key(如key="foo.bar")有垃圾值rubbish(如rubbish = "rubish-123987401234-zbert-rubish")； 2 key相关的锁为lock(如lock = "lock.foo.bar") 3 lock为乐观锁，其超时时间为ttl(如ttl = 10s) 1 强一致性系统的读写流程 强一致性系统要求缓存和数据库的数据实时一致。这就要求写操作期间既要防止多个写请求之间发生冲突，又要防止读请求与其发生冲突。 写流程 func write(key, value) err { err = "okay" // 1 生成本次lock的随机值rand，然后申请lock； rand = time().now() * getpid()