memcached 和 mysql 结合使用的两种实现选择？
时间 2021-02-13
标签
java
mysql
redis
sql
数据库
缓存
服务器
网络
架构
框架
这是我在知乎上抛出的一个问题"咱们的应用已经决定采mysql+memcached 的方式，针对的数据库版本是 mysql 5.1，目前已经进行了半个月的编码实现：
1.采用的是 ”memcached 和mysql 独立的实现方式，在编码层控制读 memcached，找不到再去数据库读，写数据库，而后再去更新 memcached，在这个过程发现逻辑复杂度比较高。
2.如今发现 “Using the MySQL memcached User-Defined Functions” 的实现方式，是经过触发器解决以上复杂逻辑的，从个人感受上来看，应该是下降了代码复杂度。
我想诸位老师帮助我从理论上分析一下这两种方式的利弊，固然最好从实战角度分析二者的利弊，或者二者在使用上有什么值得注意之处，哪一种更好，谢谢。"
各位老师的回答以下：
1.建议在应用层直接处理，而不要使用MySQL memcached User-Defined Functions
卢钧轶，MySQL DBA
虽然我的没用过memcached UDF，可是作过简单的评估，主要有如下几点以为不适用于production。
1. 增长了Memcached和MySQL之间的耦合性。
试想若是UDF指向的memcached挂了，trigger方式调用的UDF是不会接收到报错返回的，程序段天然也没法作相应处理。
2. 增长了MySQL的服务器压力。
MySQL自己就是一个对服务器性能要求较高的DBMS，本来简单的App <--> Memcached，如今变成了 App <---> MySQL <---> Memcached ，无形中增长了MySQL没必要要的转发压力（网络，CPU的损耗）
3. 运维困难。
某台Memcached如需升级，分离式架构只须要修改APP配置文件。而UDF的方案就须要修改相应的trigger，trigger是很难进行版本控制和批量下发管理的，无形中对运维形成了很大的困难
结合这位老师的思路通过本身的进一步考察，单单对于第一点，我以为就能够抛弃使用memcached UDF了，做为一个为上万客户提供服务的后台程序，容错，单点故障是必需要考虑并处理的，若是没法准确知道错误的发生，就很难迅速进行补救；
2.给出在应用层简化处理memcached逻辑的思路
范凯，互联网创业者，JavaEye网站创始人
>>在编码层控制读memcached，找不到再去数据库读，写数据库，而后再去更新memcached，在这个过程发现逻辑复杂度比较高。
若是你的应用数据的粒度划分足够细，而且配合良好的ORM层对象缓存，那么没有任何逻辑复杂度，代码根本不须要涉及这些部分，都是ORM层缓存自动处理掉了。
通过个人进一步考察，相关的ORM框架有基于java的，C#的，因为咱们的项目是使用C++语言实现，目前我尚未找到与之对应的相关ORM框架。
3.给出在应用层作memcached和mysql结合的使用建议
曹政
我喜欢在应用层作，没以为逻辑复杂在哪里。
几个要点
1：memcache和mysql的连接时间，若是两个连接同时开启，先开启的会影响后开启的，好比memcache先开启连接，而后开启mysql，如memcache阻塞，程序未及时释放，会连带致使mysql崩溃，这种状况之前遇到过，记住连接必须加超时限制，防止连带阻塞现象。或者，释放memcache链接后，再开启mysql连接（这样不利于程序封装）
2：memcache命中率如不高，不如不用。作memcache应用后，第一件事情是测试命中率状况，不能认为加了缓存就必定能够提升效率。
3：若是数据块较大，放在memcache中读取的效率或许不如mysql。
4：随时监控swap分区占用状况，确保内存使用合理。
5：memcached适合简单的key-value查询，若是涉及结构性内容，或者排名类应用，建议使用redis.