memcached 穿透mysql_memcached 和 mysql 结合使用的两种实现选择?

  • A+
所属分类:Mysql

memcachedmysql 结合使用的两种实现选择?

这是我在知乎上抛出的一个问题”我们的应用已经决定采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.

本文转自永远的朋友博客51CTO博客,原文链接http://blog.51cto.com/yaocoder/1016257如需转载请自行联系原作者

yaocoder

  • 我的微信
  • 这是我的微信扫一扫
  • weinxin
  • 我的微信公众号
  • 我的微信公众号扫一扫
  • weinxin