项目优化：当使用redis减少数据库压力时，遇到redis写入失败，造成读取数据问题的解决方案

场景：

我们项目用到了mq，有一个专门的服务在跑异步任务去发mq，这个mq的数据不是从数据库里面查的，而是从redis里面取的，之所以这么做，有两个原因：
1、使用redis减少数据库的压力；
2、本来异步任务是放在生产环境中的，包括涉及的异步任务表，都是和生产环境在一起的，那么异步任务多的时候，就会对生产环境造成压力，比如数据库压力、cpu等，所以后来将异步任务专门抽成一个服务，并专门给该项目做一个异步任务数据库和表，就是为了减少生产环境的压力。生产环境通过redis将数据传递给异步任务服务。

那么现在出现的问题是：

生产环境在写入redis数据时，在极少数情况下会存在断连的情况（确实遇到过），或者别的情况，导致写入失败，这个时候异步任务去读取redis的时候，就会读取不到数据。

我这边想到的解决方案有几种：

1、当redis写入失败的时候，重新再set写入一次，当两次都写入失败的情况下，我们在读取redis地方重新进行一次数据处理（和redis处理数据的过程一样），然后放入mq，这种重新进行一次数据处理是万不得已的做法，主要是提高容错率，保证生产环境的业务能正常走下去，就算慢点也能接受，因为很少发生这种redis写入失败的情况。
2、在生产环境也添加一个异步任务服务，和对应的数据库表，但是一般我们不适用它，只有我们redis写入失败的情况下，才操作，这样异步任务的执行直接在生产环境下进行了，当redis写入成功时，依然通过异步任务服务来完成。相比较第一种，第二种是从该类问题的层面出发的，可以解决一类这种问题， 而不是具体某个业务场景。

最终采取的方案：我们先采用的是第一种，先上线避免该场景下的问题再次发生，后来又全面排查了一下项目中涉及该类问题的业务场景，升级为第二种方式解决。