认识达内从这里开始

微服务架构开发是目前大多数软件开发程序员都在学习与应用的一种软件编程开发方式，下面我们就通过案例分析来简单了解一下，微服务架构开发技术应用常见问题分析。

1、为什么队列需要持久化?

持久化是为了解决网络抖动或者崩溃导致数据丢失的问题，在数据从业务服务到队列，队列自身处理，再从队列到缓存处理程序，中间都可能丢失数据。为了解决丢失数据的问题，需要发送时确认、队列自身持久化、接收时确认;但是需要注意确认机制可能会导致重复数据的产生，因为在未收到确认时就需要重新发送或接收，而数据实际上可能被正常处理，只是确认丢失了;确认机制还会降低队列的吞吐量，但是根据我们的定义业务静态数据的变更频率应该不高，如果同时还需要较高的并发分片是个不错的选择。

这里持久化队列推荐选择RabbitMQ，虽然吞吐量支持的不是很大，但是各方面综合不错，并发够用就好。

2、为什么需要数据一致检查程序?

在业务服务操作完关系数据库后，数据发送到队列之前(或者不用队列就是直接写入缓存之前)，业务服务崩溃了，这时候数据就不能更新到缓存了。还有一种情况是Redis发生了故障转移，master中的更新没有同步到slaver。通过引入这么一个检查程序，定时的检查关系数据库数据和缓存数据的差别，如果缓存数据比较陈旧，则更新之。这样提供了一种极端情况下的挽救措施。

这个检查程序的运行频率需要综合考虑数据库压力和能够承受的数据陈旧时间，不能把数据库查死了，也不能陈旧太久导致大量数据不一致。可以通过设置上次检查时间点的方式，每次只检查从上次检查时间点(或者近几次，防止Redis故障转移数据未同步的问题)到本次检查时间点发生变更的数据，这样每次检查只对增量变更，效率更高。

同时需要理解在分布式系统中，微服务架构下，数据不一致是经常出现的，必须在一致性和可用性之间做出权衡，尽力去降低影响，比如使用准实时或终一致性。

3、只要数据一致检查程序是不是就够了?

假设没有缓存处理程序，通过定时同步关系数据库和缓存数据库是不是就够了呢?这还是取决于业务，如果是车型库这种数据，增加一个新的车型，本来之前就没有，时间上并不是很敏感，这个是可以的。但是对于新增了用户或者车辆，数据消费者还是希望能够马上使用新的数据进行处理，越快越好，这时使用同步或者准同步更新就能更加贴近需求。

4、为什么不用缓存过期机制?

使用缓存过期机制可以不需要缓存处理程序和数据一致检查程序，业务服务先从Redis查询数据，如果数据存在就直接返回，如果不存在则从关系数据库查询，然后写入Redis，然后再返回，这也是一种常用的缓存处理机制，网上可以查询到很多，很多人用的也很好。

但是缓存的过期时间是个问题：缓存多长时间过期，设置的短可以降低数据的陈旧，但是会增加缓存穿透的概率，即使采用随机的缓存过期时间，在Redis重启或者故障转移的情况下还是会可能导致缓存雪崩，雪崩的情况下采用数据预热机制，也可能会导致服务更长时间的不可用;设置的长可以提升缓存的使用率，但是增加了数据陈旧，在上边对静态数据的定义中对其准确率和实时性都有较高的要求，业务上能不能接受需要考虑。而且如果操作数据和查询存在波动的峰谷，是不是要引入动态TTL的机制，以达到缓存使用和直接访问数据库的一种平衡，这就需要权衡业务需求和技术方案。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请加danei0707学习了解。欢迎关注“达内在线”参与分销，赚更多好礼。