第三方应用如何正确使用CMEM----经验教训

背景：

      虽然CMEM也支持memcached协议接入，但是在本质上和memcached是不同的，早期的很多开发者并没有意识到这一点，也因此出现了一系列问题，本文主要用来谈谈这些问题，以便有助于第三方开发者能正确的使用CMEM。

 

差异分析：

重大差异一，memcached是cache, CMEM是永久存储。

重大差异二，实现分布式的方式不同。memcached是client实现的分布式，而CMEM是由一个代理层实现的分布式，架构的不同决定了可控性上有所不同。

 

风险点：

 
      一.memcached是cache, CMEM是永久存储，所以memcached协议认为cache里的数据是不可靠的，即使读不到，还可以从sql里去拉取，因此，当出现网络变更或网络异常时，API会发现本来数据是存在的，但是读不到数据了，因此来促使你从sql里拉数据。而应用切换到CMEM get不到数据后，直接就执行初始化了。
      解决方案是，在添加数据时，明确使用add，修改数据最好使用replace,另外可以同时使用CMEM扩展的get_ext协议。
 
     二.memcached的分布式是由api做的，而CMEM的是由服务端做的，所以目前版本的CMEM在同一条连接上不支持异步IO，只支持一问一答方式的访问。
 

一些10年左右的案例：

     1.应用A，进行数据割接过程中，出现了在线用户，回档到一级，原因见风险点一。
 
     2.应用B,  经常反馈偶尔有数据回滚，原因见风险点一。
 
     3.应用C，发现有数据数据回滚，经查询是同一用户对应的key发生了变化，建议openid对应的key固定，如果要发生key策略变更，这种key最好保存一个备份。
 
     4.应用D，发现有用户掉级，原因是写错了表，但这两张表key的策略是相同的，建议表与表直接的key策略不要相同，这样即使写错了表，数据还在，后续我们会做白名单，但一个应用多张表，可能还是需要用户自己保证key最好不冲突的。
 
     5.应用E, 上线时发现偶尔有错误，未加理会，后当用户量增多时，发现基本不可访问，后来发现使用了spymemcached api,查询发现该api只支持异步，风险点二。

 

目前大部分开发者都能遵守CMEM注意事项，基本很少有用户犯类似错误了，即使犯了没关系，CMEM支持回档功能，

但是还是建议用户在使用CMEM前请仔细阅读官方文档，避免恢复数据带来的麻烦。

 

了解更多：

 

腾讯开放云

http://wiki.open.qq.com

腾讯开放云CMEM wiki

http://wiki.open.qq.com/wiki/CMEM%E6%9C%8D%E5%8A%A1%E4%BB%8B%E7%BB%8D

腾讯移动云

http://www.qcloud.com/