小公司做网站,做网站 用哪个网盘好,com一级域名,美橙互联同类型网站前言
一. 解决缓存不命中#xff08;高并发操作击穿打挂DB的风险#xff09;
当并发量打的时候#xff0c;当我们的缓存过期时#xff0c;就算到数据库的比例偏小的时候#xff0c;我们的请求时比较大的。那也会存在数据库崩掉的情况。解决方案想法如下#xff08;总体…前言
一. 解决缓存不命中高并发操作击穿打挂DB的风险
当并发量打的时候当我们的缓存过期时就算到数据库的比例偏小的时候我们的请求时比较大的。那也会存在数据库崩掉的情况。解决方案想法如下总体思想就是全放到redis中但是DB要更新的时候Redis也需要更新那就存在缓存击穿的情况对于这个情况有以下的思路 加锁首先加锁只能对同一个查询对象对于多的查询是不可选的并且加锁对我们的效率大打折扣我们在系统中非必要的情况都是在进行无锁化编程 2.缓存预热当系统启动时将缓存进行预热。对于使用缓存我们还是需要考虑数据一致性的问题面对这个问题我们很容易想到设置缓存的过期时间但是对于高并发的场景我们就最好不要设置缓存过期因为对于高并发的时候我们还是存在击穿的情况造成数据库挂掉。对于此种情况我们最好设置永不过期。对于永不过期的情况我们最好设置的设计就是使用MQ来保证数据的一致性。然后注意解决消息的可靠性问题即可这种方式实现起来很简单也没有什么侵入性。 二. 如何使用Binlog实时更新Redis缓存(当没部署Mq时)
BinLog是MySql的操作日志还有一个是事务日志redoLog和undoLog对于着两种日志mySql为了保证双写一致使用的是2pc双阶段提交 三. Canal详解与实战
阿里开源的监听解析mySql的操作日志的开源框架 四. 基于Binlog实现跨系统实时数据同步 五. 如何实现不停机更换数据库
一步一步进行改造了解热开关对系统改造的重要性都要兜底方案就是可以返回上一个版本所有的系统设计都需要重要 六. 如何更安全地实现数据备份和恢复
BinLog的使用
整体的使用链路
建议再开一个专门的服务来监听BinLog让一些东西保持在我们自己可控的范围。
binlog是mysql提供的数据同步机制很好的解决了主从分离、读写库分离等业务。而我们可以构建一个中间件系统“伪造”成master的一个slave。当读取了binlog中的数据变化后根据相应的业务场景做各种业务处理。而目前我接触到的最常见的就是第一个场景——数据异构数据一致可以异构到其他表中也可以异构到其他数据引擎中比如Elastic Search/redis。 来自网络 binlog可能中使用Canal需要对DB的binLog特别了解所以使用MQ来同步更为容易可读性更高 使用Mq来保证数据的一致性
这个方案就比较简单了也是最常使用的。但是引入中间件增加了系统数据的链路和系统的复杂度。
数据库迁移或者表对表的数据迁移都和这个差不多
实现不停机更换数据库
所以我们在设计迁移方案的时候一定要保证每一步都是可逆的。也就是必须保证每执行完一个步骤,一旦出现任何问题都能快速回滚到上一个步骤。这是设计这种升级类技术方案的时候比较容易忽略的问题。
将旧数据全量同步到新库中但是这时数据还会写到旧库中。我们不仅要向新库复制数据还要保证新旧两个库的数据是实时同步的。所以需要用一个同步程序来实现新旧两个数据库的实时同步。(可以加一个热控制开关全局控制) 方案 1.使用mq 推荐简单coding需要部署mq2.使用binlog 然后需要改造一下订单服务业务逻辑部分不需要变动数据访问的 DAO 层需要进行如下改造 1支持双写新旧两个库并且预留热切换开关能通过开关控制三种写状态:只写旧库、只写新库和同步双写。 2支持读取新旧两个库同样预留热切换开关控制读取旧库还是新库。
3)然后上线新版的订单服务这个时候订单服务仍然是只读写旧库不读写新库。让这个新版的订单服务稳定运行至少一到两周的时间其间我们不仅要验证新版订单服务的稳定性还要验证新旧两个订单库中的数据是否保持一致。这个过程中如果新版订单服务出现任何问题都要立即下线新版订单服务回滚到旧版本的订单服务。 3、稳定一段时间之后就可以开启订单服务的双写开关了。开启双写开关的同时需要停掉同步程序。这里有一个需要特别注意的问题是这里双写的业务逻辑一定是先写旧库再写新库并且以旧库的结果为准。 如果旧库写成功新库写失败则返回成功但这个时候要记录日志后续我们会根据这个日志来验证新库是否还有问题。如果旧库写失败则直接返回失败同时也不再写新库了。这么做的原因是不能让新库影响到现有业务的可用性和数据准确性。上面这个过程如果出现任何问题都要关闭双写,回滚到只读写旧库的状态。 切换到双写之后,新库与旧库的数据可能会出现不一致的问题。原因有两点 一是停止同步程序和开启双写这两个过程很难做到无缝衔接 二是双写的第略也不能保证新旧库的强一致性。对于这个问题,我们需要上线一个比对和补偿的程序用于比对旧库最近的数据变更然后检查新库中的数据是否一致如果不一致则需要进行补偿。
开启双写之后还需要稳定运行至少几周的时间并且在这期间我们需要不断地检查以确保不能有旧库写成功、新库写失败的问题。如果在几周之后比对程序发现新旧两个库的数据没有不一致的情况那就可以认为新旧两个库的数据一直都是保持同步的。 4、接下来就可以用类似灰度发布的方式把读请求逐步切换到新库上。同样运行期间如果出现任何问题都要再切回到旧库。 5、将全部读请求都切换到新库上之后其实读写请求已经全部切换到新库上了虽然实际的切换已经完成,但后续还有需要收尾的步骤。再稳定一段时间之后就可以停掉比对程序把订单服务的写状态改为只写新库。至此旧库就可以下线了。注意在整个迁移过程中,只有这个步骤是不可逆的。由于这一步的主要操作就是摘掉已经不再使用的旧库因此对于正在使用的新库并不会有什么影响实际出问题的可能性已经非常小了。 总结数据迁移这种 1.一步一步的进行迁移切勿一口吃成一个胖子2.对热切换开关的使用特别重要3.必须保证每轮都要返回回滚到上一个版本不能影响系统的总体数据4.补偿机制特别重要一定要做好备份特别感谢mark老师的教导和慷慨解囊
