数据库如何同步的,两台服务器数据库同步

在使用redis做缓存时数据库如何同步的，会和做分布式事务有同样的问题，就是数据库如何同步的你没有办法百分之百的保证数据的强一致性，我们只能通过技术的手段，来减少数据不一致的时间

在面试的时候，问到怎么去保证redis数据的一致性，很多人说更新数据库时，同步更新redis，但是用这种方案，无论是先提交数据库在更新redis，或是先更新redis在提交数据库，都会有一方成功但是另一方失败的可能，造成数据的不一致性，而且还有一种可能，两个线程同时去更新，线程a先更新了数据库，然后线程b又去更新了数据库并且把数据更新到了redis，然后线程a又去更新了redis，这样两个线程全部执行结束后，数据库中存的数据是线程b的数据，而redis中存的是线程a的数据，依然会造成数据的不一致性。所以这种方案是不可取的。

还有人说，对redis做先删后插，即更新数据库成功后，提交事务之前，先把redis数据删除，如果删除成功，则提交数据库事务，删除失败，则回滚事务。这样在提交事务后，如果有查询的请求过来，发现redis中的数据已被删掉，则会去数据库查询，将数据库最新的数据在回写到redis，这样就保证了数据的一致性。这种方案貌似看起来是没有问题的，但是其实还是有漏洞的，如果在你删除redis成功之后，数据库提交之前，又有查询的请求过来了，这时发现redis没有数据，会自动去数据库查询，但是由于此时数据库的事务还没有提交，数据库中存的还是旧数据，此时又把旧数据回写到redis了，依然会造成数据的不一致的，针对这种问题的解决方案，有很多人说，加锁，或是加队列，让查询的请求和更新的请求由并行变为串行，就可以解决问题了，但是这种方案就已经违背了我们用redis的初衷，我们用redis做缓存的目的就是为了提高效率，你这又加锁又加队列的，效率反而降下来了，那我们还用redis干嘛呢数据库如何同步的？

正确的做法是，还是按照上面的先删后插的方案，只不过做了一下改进，做个双删机制，既数据库提交事务之前删一次redis，事务提交之后，在删一次redis，这样的话，即使在事务提交之前，有查询请求将旧数据回写到redis了，我在事务提交之后，在删一次redis，下次查询过来，就由会把新的数据回写到了redis了。

但是这样还是会有个问题，就是说我在事务提交之前，查询请求把旧数据回写到redis了，但是在事务提交之后，我又删除redis失败了，怎么办数据库如何同步的？这就是我开篇所说的，没有办法去百分之百的保证数据的强一致性，只能尽最大的努力去减少数据不一致的时间，遇到这种情况，你可以采取异步重试的机制，或者依赖于key的过期时间，key过期后会自动从redis中删掉。

那可能有人会问了，按照这种方案的话，是不是只要提交事务之后删一次redis就可以了，在提交事务之前删redis没啥意义啊。但是还是像我开篇所说的，我们要尽最大努力去减少数据不一致的时间，如果只是提交事务之后去删一次，一旦删除失败了，就会造成数据不一致性，只能通过重试机制或key的过期时间来保证它的最终一致性，但是你如果在提交事务之前也删一次，并且提交事务前也没有查询请求将旧数据回写到redis，此时你提交事务后，删除失败了也无所谓，我依然可以保证数据的一致性。那在这种模式下，什么时候会出现数据不一致呢，只有一种情况，你在提交事务之前，redis删除成功了，此时又有查询请求将旧数据库回写到了redis，然后再事务提交成功之后，又redis又失败了。但是大家可以想象一下，这种概率的发生会有多小，对redis做同样的操作，你上一秒还能成功，下一秒就失败咯，此时又偏偏来个查询的请求把旧数据回写到redis了，这种概率的发生，简直太小了，而且即使出现了这种问题也没关系，我们依然可以采用重试机制或者key的过期时间来保证它的最终一致性。

这样的方案看起来是完美了，但是在实现上还是有问题的， *** 作数据库和redis都是在dao层，但是事务的提交是在service层控制的，而且service和dao层是隔离的，我在service层提交事务后，我并不知道需要删除redis的哪些数据，而且每写一个接口，都需要去手动调一个删除后redis数据的 *** ，也是挺麻烦的。这个问题我是这样解决的，在dao层更新数据库成功后，我会把需要删除的redis的key ，放到threadlocal里面，然后在拦截器里面，获取这个threadlocal，去删除redis，而且此时去删除redis，是否删除成功，用户是不需要关心的，所以为了提高接口的响应效率，可以做个异步删除。但是这种说的都是以接口的方式，把获取threadlocal *** 和异步删除的 *** 都写在拦截器了，不需要每次都手工去调，但是如果不以接口的方式，以定时任务的方式，不走拦截器，那这种就只能没次都手工调了。

上面说的方案，都是针对的根据id去操作唯一的一条数据，那如果在业务中，需要根据其他条件，去批量更新数据，怎么办呢，有人说先按照这些条件，把这些数据的id去查询出来，然后一个一个的去删，但是这样会有一个问题，在你查询和更新数据库之间，又有人更新了数据库，导致你查询出来的数据，和实际更新的数据是不一致的，这样就会出现问题，所以个人建议，如果真的有业务场景，还是先把这些数据查询出来，然后一条一条的去根据id做更新，不要去做批量更新，当然了，还是要根据具体业务去决定。

这都是我的一些个人看法，大家如果有不同意见，欢迎评论区讨论，让我们共同进步[微笑]