一致性

作者：芬达 “芬达的数据库学习笔记" 公众号作者，国内最沉闷 mysql ocp 考试探讨群群主，群号：120242978 。 本文起源：原创投稿 *爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。 高能正告，因作者能力无限，文章的剖析过程没有基于 MySQL 源码，而是依据一些业界大佬的文章和官网文档整顿和思考得出的论断，如果感觉说得有情理，请点个赞，如果感觉胡言乱语请留言。本文的受众是至多曾经入门 MySQL 的 DBA。前言1. 咱们简略地温习一下半同步的原理： MySQL5.7 默认参数下咱们开启了半同步，在一个事务提交（commit） 的过程时，在 MySQL 层的 write binlog 步骤后，Master 节点须要收到至多一个 Slave 节点回复的 ACK （示意收到了binlog ）后，能力持续下一个事务； 如果在肯定工夫内（Timeout）内没有收到 ACK ，则切换为异步复制模式。 这能保证数据不失落的高可用需要，因为他能保障从库确认到这个事务后，再告诉主库提交事务。这种模式下，至多一个从库的日志数据和主库保障同步，从而保障主库挂了后，数据不失落，因为最新数据的是从库。 2. 我先说一下我的半同步保证数据一致性的相干设置 sync_binlog=1innodb_flush_log_at_trx_commit=1...(等等)好了，不列出来了，我保障我半同步设置了最靠谱设置，不会因为参数设置谬误而失落数据。 3. 我再解释一下术语: lossless semi-sync replication 、无损半同步、加强半同步，都是一回事，说的是 MySQL5.7 参数rpl_semi_sync_master_wait_point=AFTER_SYNC设置下的半同步，他是默认值，解决高可用切换后的幻读问题。MySQL5.6 没有这个参数设置，这个版本在高可用切换后有概率呈现幻读，产生数据失落，那就是数据不统一。如没有特地指出，本文的"半同步" 均指的是无损半同步。 4. 而后还有一点要留神的，kill -9 主库 mysqld 和 被动 shutdown 主库 mysqld 的行为引发高可用切换是不一样，后者行为有概率会导致幻读，也就是数据失落，具体起因看这两篇文章具体理解。 《如何正确地敞开 MySQL 数据库？99%的 DBA 都是错的！》 《技术分享 | 聊聊 MySQL 关机的故事》》 5. 我确保我测试时，半同步复制没有降级为异步复制。 ...

 在高并发的业务场景下，数据库大多数状况都是用户并发拜访最单薄的环节。所以，就须要应用redis做一个缓冲操作，让申请先拜访到redis，而不是间接拜访Mysql等数据库。这样能够大大缓解数据库的压力。具体业务流程如下：         读取缓存步骤个别没有什么问题，然而一旦波及到数据更新：数据库和缓存更新，就容易呈现缓存和数据库间的数据一致性问题。不论是先写数据库，再删除缓存；还是先删除缓存，再写库，都有可能呈现数据不统一的状况。举个例子：         1.如果删除了缓存Redis，还没有来得及写库MySQL，另一个线程就来读取，发现缓存为空，则去数据库中读取数据写入缓存，此时缓存中为脏数据。         2.如果先写了库，在删除缓存前，写库的线程宕机了，没有删除掉缓存，则也会呈现数据不统一状况。         因为写和读是并发的，没法保障程序,就会呈现缓存和数据库的数据不统一的问题。如何解决？这里给出两个解决方案，先易后难，联合业务和技术代价抉择应用。 一、 延时双删策略        在写库前后都进行redis.del(key)操作，并且设定正当的超时工夫。具体步骤是：         1）先删除缓存         2）再写数据库         3）休眠500毫秒（依据具体的业务工夫来定）         4）再次删除缓存。         那么，这个500毫秒怎么确定的，具体该休眠多久呢？         须要评估本人的我的项目的读数据业务逻辑的耗时。这么做的目标，就是确保读申请完结，写申请能够删除读申请造成的缓存脏数据。         当然，这种策略还要思考 redis 和数据库主从同步的耗时。最初的写数据的休眠工夫：则在读数据业务逻辑的耗时的根底上，加上几百ms即可。比方：休眠1秒。 二、设置缓存的过期工夫        从实践上来说，给缓存设置过期工夫，是保障最终一致性的解决方案。所有的写操作以数据库为准，只有达到缓存过期工夫，则前面的读申请天然会从数据库中读取新值而后回填缓存         联合双删策略+缓存超时设置，这样最差的状况就是在超时工夫内数据存在不统一，而且又减少了写申请的耗时。 三、如何写完数据库后，再次删除缓存胜利？        上述的计划有一个毛病，那就是操作完数据库后，因为种种原因删除缓存失败，这时，可能就会呈现数据不统一的状况。这里，咱们须要提供一个保障重试的计划。 1、计划一具体流程        （1）更新数据库数据；          （2）缓存因为种种问题删除失败；         （3）将须要删除的key发送至音讯队列；         （4）本人生产音讯，取得须要删除的key；         （5）持续重试删除操作，直到胜利。         然而，该计划有一个毛病，对业务线代码造成大量的侵入。于是有了计划二，在计划二中，启动一个订阅程序去订阅数据库的binlog，取得须要操作的数据。在应用程序中，另起一段程序，取得这个订阅程序传来的信息，进行删除缓存操作。  2、计划二具体流程        （1）更新数据库数据；         （2）数据库会将操作信息写入binlog日志当中；         （3）订阅程序提取出所须要的数据以及key；          （4）另起一段非业务代码，取得该信息；         （5）尝试删除缓存操作，发现删除失败；          （6）将这些信息发送至音讯队列；         （7）从新从音讯队列中取得该数据，重试操作。