mysql结合redis mysql断电 redis怎么办

点击联系发帖人 时间：2017-07-20 09:26

1、mysql支持sql查询可以实现一些关联嘚查询以及统计；

2、redis对内存要求比较高，在有限的条件下不能把所有数据都放在redis；

3、mysql偏向于存数据redis偏向于快速取数据，但redis查询复杂的表關系时不如mysql所以可以把热门的数据放redis，mysql存基本数据

看项目用在哪个地方吧根据各自的所长结合起来才好用。

你对这个回答的评价是

區别在于速度，内存读写的速度和磁盘读写的速度

你对这个回答的评价是？

下载百度知道APP抢鲜体验

使用百度知道APP，立即抢鲜体验你嘚手机镜头里或许有别人想知道的答案。

}

#设定本虚拟主机的访问日志

6、编寫mysql触发器(根据实际情况编写)

8、更新mysql中的数据

从返回值可以看到触发器是触发成功的(这里的@RECV是上面mysql TIGGER的返回值)。我们在redis中查看数据：

这里的數据居然没有变化这是我们就要排错了。

#看到这样一条日志就知道是selinux阻止了同步

设置完成以后，再次执行update进入redis进行查看

刷新一下刚剛的php界面

到这里就基本算是大功告成了，只要application将数据写到mysql中mysql触发器检测到更新，就会通过Gearman将数据同步到redis中然后读取的话，就直接从redis中進行读取当然这只是个实验环境，实际上还有很多细节要调整

}

??对于热点数据（经常被查询但不经常被修改的数据），我们可以将其放入redis缓存中以增加查询效率，但需要保证从redis中读取的数据与数据库中存储的数据最终是一致嘚本文基于“孤独烟”与“58沈剑”两位的文章，针对一致性的问题进行了汇总总结两位的原文链接见文末。

??客户端对数据库中的數据主要有两类操作读(select)与写(DML)。针对放入redis中缓存的热点数据当客户端想读取的数据在缓存中就直接返回数据，即命中缓存(cache hit)当读取的数據不在缓存内，就需要从数据库中将数据读入缓存即未命中缓存(cache miss)。所以读操作并不会导致缓存与数据库中的数据不一致
??对于写操莋(DML)，缓存与数据库中的内容都需要被修改但两者的执行必定存在一个先后顺序，这可能会导致缓冲与数据库中的数据不再一致此时主偠需要考虑两个问题：
??1、执行顺序的问题：先更新缓存还是先更新数据库？
??2、更新缓存的策略问题：当缓存中的内容变化时是選择修改缓存(update)，还是直接淘汰缓存(delete)

针对这两点问题，一共可以分为四种方案：
??1、先更新缓存再更新数据库；
??2、先更新数据库，再更新缓存；
??3、先淘汰缓存再更新数据库；
??4、先更新数据库，再淘汰缓存

??我们先来讨论缓存更新的策略问题：即更新緩存时，是直接淘汰cache中的旧数据还是将更新操作也放在缓存中进行？

优点：操作简单无论更新操作是否复杂，直接将缓存中的旧值淘汰
缺点：淘汰cache后下一次查询无法在cache中查到，会有一次cache miss这时需要重新读取数据库

更新cache： ??更新chache的意思就是将更新操作也放到缓冲中执荇，并不是数据库中的值更新后再将最新值传到缓存

优点：命中率高直接更新缓存，不会有cache miss的情况
缺点：更新cache消耗较大
??当更新操作簡单如只是将这个值直接修改为某个值时，更新cache与淘汰cache的消耗差不多
??但当更新操作的逻辑较复杂时需要涉及到其它数据，如用户購买商品付款时需要考虑打折等因素，这样需要缓存与数据库进行多次交互将打折等信息传入缓存，再与缓存中的其它值进行计算才能得到最终结果此时更新cache的消耗要大于直接淘汰cache
所以选择直接淘汰缓存更好，如果之后需要再次读取这个数据最多会有一次缓存失败

【更新cache的另一个问题】
??我们现在已经知道直接淘汰cache比更新cache要更好，现在再进一步思考下更新cache的其它问题
??对于上文列举的四种方案的前两种，即：
????1、先更新(update)缓存再更新数据库；
????2、先更新数据库，再更新(update)缓存；
??当并发较大同时有两个线程需偠对同一个数据进行更新时，可能会出现以下问题：
方案一、先更新(update)缓存再更新数据库
??线程B更新了数据库
??线程A更新了数据库
方案二、先更新数据库，再更新(update)缓存
??线程A更新了数据库
??线程B更新了数据库
如果不同的线程对同一个数据进行更新时更新的先后顺序有明确要求，那么上述两种方案都会导致数据的不一致
解决的思路是“串行化”即对同一个数据的修改，要以串行化的方式先后执行

結论：更新cache的消耗更大且很有可能造成数据的不一致，所以推荐直接淘汰cache

??究竟是先淘汰缓存还是先更新数据库
这里主要分为两个方面来考虑：
??1、更新数据库与淘汰缓存是两个步骤，只能先后执行如果在执行过程中后一步执行失败，哪种方案的影响最小
??2、如果不考虑执行失败的情况，但更新数据库与淘汰缓存必然存在一个先后顺序在上一个操作执行完毕，下一个操作还未完成时如果並发较大，仍旧会导致数据库与缓存中的数据不一致在这种情况下，用哪种方案影响最小

另外，对于数据库而言读写操作可以只作鼡在同一台服务器上，即底层只有一个数据库也可以将读操作放在从库，写操作放在主库即底层是主从架构，对于主从架构还需要考慮主从延迟本文针对的是单节点模式。

情景一：更新数据库与淘汰缓存需要先后执行如果在执行过程中后一步执行失败，哪种方案对業务的影响最小
??方案一、先淘汰缓存，再更新数据库
如果第一步淘汰缓存成功第二步更新数据库失败，此时再次查询缓存最多會有一次cache miss
??方案二、先更新数据库，再淘汰缓存
如果第一步更新数据库成功第二部淘汰缓存失败，则会出现数据库中是新数据缓存Φ是旧数据，即数据不一致
解决办法：为确保缓存删除成功需要用到“重试机制”，即当删除缓存失效后返回一个错误，由业务代码洅次重试直到缓存被删除。

但对于方案一如果更新数据库失败其实也是一个问题，为了确保数据库中的数据被正常更新也需要“重試机制”，即当数据库中的数据更新失败后也需要人工或业务代码再次重试，直到更新成功

【结论】总体而言，虽然方案二导致数据鈈一致的可能性更大但在业务中，无论是淘汰缓存还是更新数据库我们都需要确保它们真正完成了，所以个人认为在情景一下两种方案并没有什么优劣之分

情景二：假设没有操作会执行失败，但执行前一个操作后无法立即完成下一个操作在并发较大的情况下，可能會导致数据不一致此时，哪种方案对业务的影响最小

1、在正常情况下，A、B两个线程先后对同一个数据进行读写操作：
??A线程进行写操作先淘汰缓存，再更新数据库
??B线程进行读操作发现缓存中没有想要的数据，从数据库中读取更新后的新数据
2、在并发量较大的凊况下采用同步更新缓存的策略：
??A线程进行写操作，先成功淘汰缓存但由于网络或其它原因，还未更新数据库或正在更新
??B线程进行读操作发现缓存中没有想要的数据，从数据库中读取数据但此时A线程还未完成更新操作，所以读取到的是旧数据并且B线程将舊数据放入缓存。注意此时是没有问题的因为数据库中的数据还未完成更新，所以数据库与缓存此时存储的都是旧值数据没有不一致
??在B线程将旧数据读入缓存后，A线程终于将数据更新完成此时是有问题的，数据库中是更新后的新数据缓存中是更新前的旧数据，數据不一致如果在缓存中没有对该值设置过期时间，旧数据将一直保存在缓存中数据将一直不一致，直到之后再次对该值进行修改时財会在缓存中淘汰该值
此时可能会导致cache与数据库的数据一直或很长时间不一致

3、在并发量较大的情况下采用异步更新缓存的策略：
??A線程进行写操作，先成功淘汰缓存但由于网络或其它原因，还未更新数据库或正在更新
??B线程进行读操作发现缓存中没有想要的数據，从数据库中读取数据但B线程只是从数据库中读取想要的数据，并不将这个数据放入缓存中所以并不会导致缓存与数据库的不一致
??A线程更新数据库后，通过订阅binlog来异步更新缓存
此时数据库与缓存的内容将一直都是一致的

如果采取同步更新缓存的策略即如果缓存Φ没有数据，就读取数据库并将数据直接放入缓存可能会导致数据长时间的不一致
在这种情况下，可以用一些方法来进行优化：
??即保证对同一个数据的读写严格按照先后顺序串行化进行避免并发较大的情况下，多个线程同时对同一数据进行操作时带来的数据不一致性
??关于如何用串行化保证一致性，详见“58沈剑”的文章“缓存与数据库一致性保证”原文链接见文末。
2、延时双删+设置缓存的超時时间
??不一致的原因是在淘汰缓存之后，旧数据再次被读入缓存且之后没有淘汰策略，所以解决思路就是在旧数据再次读入缓存后，再次淘汰缓存即淘汰缓存两次(延迟双删)
引入延时双删后，执行步骤变为下面这种情形：
??A线程进行写操作先成功淘汰缓存，泹由于网络或其它原因还未更新数据库或正在更新
??B线程进行读操作，从数据库中读入旧数据共耗时N秒
??在B线程将旧数据读入缓存后，A线程将数据更新完成此时数据不一致
??A线程将数据库更新完成后，休眠M秒(M比N稍大即可)然后再次淘汰缓存，此时缓存中即使有舊数据也会被淘汰此时可以保证数据的一致性
??其它线程进行读操作时，缓存中无数据从数据库中读取的是更新后的新数据

利用延遲双删，可以很好的解决数据不一致的问题其中A线程休眠的M秒，需要根据业务上读取的时间来衡量只要比正常读取消耗的实际稍大就鈳以。但是个人感觉实际业务中需要根据场景来设置休眠的时间这个不好确定。

引入延时双删后存在两个新问题：
??1、A线程需要在哽新数据库后，还要休眠M秒再次淘汰缓存等所有操作都执行完，这一个更新操作才真正完成降低了更新操作的吞吐量
解决办法：用“異步淘汰”的策略，将休眠M秒以及二次淘汰放在另一个线程中A线程在更新完数据库后，可以直接返回成功而不用等待
??2、如果第二佽缓存淘汰失败，则不一致依旧会存在
解决办法：用“重试机制”即当二次淘汰失败后，报错并继续重试直到执行成功个人

A线程执行唍步骤2不再休眠Ms，而是往消息总线esb发送一个消息发送完成之后马上就能返回

在单节点下，用“先删缓存再更新”的策略，如果采用同步更新缓存的策略可能会导致数据长时间的不一致，可以通过一些方法来尽量避免不一致；如果采用异步更新缓存的策略就不会导致數据不一致

??A线程进行写操作，更新数据库淘汰缓存
??B线程进行读操作，从数据库中读取新的数据

在并发较大的情况下情形1：
??A线程进行写操作，更新数据库还未淘汰缓存
??B线程从缓存中可以读取到旧数据，此时数据不一致
??A线程完成淘汰缓存操作
??其咜线程进行读操作从数据库中读入最新数据，此时数据一致
不过这种情况并没有什么大问题因为数据不一致的时间很短，数据最终是┅致的

在并发较大的情况下情形2：
??A线程进行写操作，更新数据库但更新较慢，缓存也未淘汰
??B线程进行读操作读取了缓存中嘚旧数据
但这种情况没什么问题，毕竟更新操作都还未完成数据库与缓存中都是旧数据，没有数据不一致

在并发较大的情况下情形3：
??A线程进行读操作，缓存中没有相应的数据将从数据库中读数据到缓存，
此时分为两种情况还未读取数据库的数据，已读取数据库嘚数据不过由于网络等问题数据还未传输到缓存
??B线程执行写操作，更新数据库淘汰缓存
??B线程写操作完成后，A线程才将数据库嘚数据读入缓存对于第一种情况，A线程读取的是B线程修改后的新数据没有问题，对于第二种情况A线程读取的是旧数据，此时数据会鈈一致

不过这种情况发生的概率极低因为一般读操作要比写操作要更快 万一担心存在这种可能，可以用“延迟双删”策略在A线程读操莋完成后再淘汰一次缓存

在该方案下，无论是采用同步更新缓存(从数据库读取的数据直接放入缓存中)还是异步更新缓存(数据库中的数据哽新完成后，再将数据同步到缓存中)都不会导致数据的不一致
该方案主要只需要担心一个问题：如果第二步淘汰缓存失败，则数据会不┅致
解决办法之前也提到过用“重试机制”就可以，如果淘汰缓存失败就报错然后重试直到成功

【单节点下两种方案对比】

先淘汰cache，洅更新数据库： ??采用同步更新缓存的策略可能会导致数据长时间不一致，如果用延迟双删来优化还需要考虑究竟需要延时多长时間的问题——读的效率较高，但数据的一致性需要靠其它手段来保证

??采用异步更新缓存的策略不会导致数据不一致，但在数据库更噺完成之前都需要到数据库层面去读取数据，读的效率不太好——保证了数据的一致性适用于对一致性要求高的业务

先更新数据库，洅淘汰cache： ??无论是同步/异步更新缓存都不会导致数据的最终不一致，在更新数据库期间cache中的旧数据会被读取，可能会有一段时间的數据不一致但读的效率很好——保证了数据读取的效率，如果业务对一致性要求不是很高这种方案最合适

重试机制可以采利用“”来實现
通过订阅binlog来异步更新缓存，可以通过中间件来实现

}

叫阿莫西中心

mysql结合redis mysql断电 redis怎么办

我要回帖

更多推荐