做电子商务网站 除了域名 网页设计 还有服务器 和网站空间怎样建设网站后台
数据一致性解决方案总结
我们在系统中，主要进行了数据冗余，那么就会带来数据一致性的问题。常见的数据一致性问题有：数据库主从同步延迟导致的读数据不一致；数据库主主之间数据的不一致；缓存和数据库之间的数据不一致。
一、数据库主从数据不一致解决方案
问题产生：
数据库主从数据不一致问题的产生一般是由于数据库主从同步时延导致的，当我们往主库中写数据之后，立刻对这个数据发起了读请求，但是此时可能数据还没有从主库同步到从库中，从而产生了数据不一致的问题。
解决方案：
我们可以借助于一个缓存，当我们操作数据库主库的时候，我们同时往缓存中放入一个 “数据库名称：表名称：主键” 组合的key，然后过期时间设置为主从同步的时延，当我们发起读请求的时候，会先去判断这个key是否存在，如果存在会强制要求读主库，如果这个key不存在，则去读取从库
二、数据库主主之间数据不一致问题解决方案
问题产生：
主库与主库之间数据不一致问题，一般出现在两个主库都提供写服务的时候，当两个主库都对外提供写服务的时候，同时两个主库之间是需要进行数据同步的，那么可能会产生相同主键的数据被覆盖掉的问题
解决方案：
1.只有一个主库对外提供写服务，另外一个主库作为一个影子主库，当主库宕机之后，立刻将流量切换到这个影子主库中
2.如果使用数据表的主键递增，那么两个主库中的表的起始ID不同，步长相等，这样可以防止同步的时候，相同主键的数据被覆盖掉
3.在业务层使用分布式ID发号器生成全局唯一的ID进行插入
三、缓存数据库数据不一致解决方案
问题产生：
当我们使用了缓存的时候，有一个无法避免的问题就是，先操作数据库还是先操作缓存，大部分业务都是需要先操作数据库的，如果更新数据库的数据成功，但是缓存操作还没有完成，此时读取操作从缓存中读取到的就是脏数据。
解决方案：
常见的缓存和数据库数据的更新有两大类分别是：
1.写时缓存
写时缓存就是 先更新数据库，然后再更新缓存 ，这种方案有个问题，那就是 容易出现读到脏数据的问题 ，比如一个线程更新完数据库后还没有更新完缓存，此时有另一个线程来读取缓存，那么就会读取到之前的老数据。
但是写时缓存的这个问题也不是没有解决办法，那就是 通过加锁，让更新数据库和更新缓存同时只能有一个线程来操作 ，但是这个解决方案的显著问题就是系统性能会变得很差。但是并不是说这种方案没有好处，它的好处就是 数据的实时性强 。线程读到的一定是最新的数据。对于对数据一致性有很强要求的场景比如 ‘金融系统’，这种方案是可以考虑的。
但是这种方案还有一个缺点就是： 如果对缓存的更新失败，需要写操作才能重新操作缓存 ，但是对于大部分业务来说，都是读多写少。这个原因其实也是写时缓存方案使用少的 主要原因 。
2.读时缓存
读时缓存就是 先更新数据库，然后将缓存删除，等下次读取操作到来时，去更新最新的缓存数据 。
注意：对于 单机的数据库 来说是可以的，但是如果是对于 主从架构 的数据库来说， 可能不太适用 ，因为会带来更多的读取脏数据问题。
对于数据库主从架构的系统来说，读时缓存有两个常用的方案:
1.延迟双删方案
更新数据库的时候，删除缓存 ，同时可以引入消息中间件mq来 发送一个延迟消息 ， 延迟一个时间之后再去删除一次缓存 。这种方案是为了 保证最终一致性 ，对于强一致性的实现支持不太好。
2.订阅binlog删除缓存方案
更新数据库的时候，等到slave数据库接收到master的binlog之后再去删除缓存 。这种方案也是为了 保证最终一致性 ，对于强一致性的实现支持不太好。
四、Redis Sentinel模式下的主从数据不一致问题解决方案
问题产生：
当我们使用Redis的Sentinel模式进行部署的时候，会遇到我们往主节点中写入数据，但是数据还没有同步到从节点中，此时又有读请求到来，读请求分配到了从节点上，就无法读取到最新的数据。
解决方案：
1.对于数据一致性要求非常强的业务场景，比如‘金融行业’我们可以在业务层使用Lettuce、Jedis Cluster客户端来将读请求强制指定到读取主节点中的数据
2.使用 min-slaves-to-write 和 min-slaves-max-lag 配置主节点写入条件，当主节点和指定数量的从节点完成同步之后才给主节点返回写入成功，这个方案会损失一定的写入可用性
e** 和 min-slaves-max-lag 配置主节点写入条件，当主节点和指定数量的从节点完成同步之后才给主节点返回写入成功，这个方案会损失一定的写入可用性
后续如果我遇到其他数据不一致的情况，会持续进行更新