memcached plugin在实践中的应用

　　应用背景介绍

　　我所在职的Oray是一家提供各种互联网服务且具有海量用户的企业，我们也一直在实践各种新技术新架构；缓存方面，我们从memcached、ttserver、redis等都有较多应用，其中redis在我们的dns体系中有着很深度的集成使用；MySQL InnoDB memcached plugin出来有挺长时间了，网上还没见到国内有把它用到生产环境的实例，我今天就给大家说下小白鼠体验。

　　创始产品花生壳是个简单的动态域名产品，用户可以用它发布自己的各类服务，从网站到各类专用数据连接；就算在中国互联网环境如此残酷同时IPv4资源在不断萎缩的今天，这个产品还在不断的发展壮大。虽然表面看起来是个简单的工具软件，但它为中国一代代的互联网人解决了很多基础的连接问题！

　　但很大一部分用户使用我们的花生壳也就是为了远程操作电脑，所以2010年，在我们埋头苦干了1年多后推出了向日葵远程控制产品，这个产品的基本功能就是让用户不需要关心IP端口等技术知识就可以远程管理控制他的所有电脑，这个产品主要依赖以下技术：

　　1、通过关系型数据库管理用户主机清单；

　　2、使用长连接维持被控在线状态；

　　3、P2P通信技术传输控制信号以及图像信号；

　　4、优化的算法尽可能的降低用户带宽占用以及提高图像质量；

　　5、其他周边技术，如HTML5免插件远程控制、远程开机等。

　　客户端、操作系统以及相关远控技术问题我们今天先不探讨，向日葵也不是一个简单的C/S结构软件，我们需要像聊天服务器那样与客户端进行实时交互，而客户端在线量一直在凶猛的增长中，我们的系统以及运维和开发团队也就不停的迭代并成长。

　　2、向日葵远程控制技术的数据需求

　　上面提到，向日葵使用关系型数据库存贮某一个用户拥有哪些主机，以及这些主机的具体相关信息；在此同时，我们也需要临时存储一些关键的实时数据：

　　1、 主机鉴权信息

　　2、 主机在线状态

　　3、 如何连接主机

　　从这些数据内容可以看出它们是实时产生且需要多方可以直接访问的，向日葵的被控端可能登陆在全国各地任意一台长连接服务器上，而试图过来访问这个被控的主控端则需要通过API服务实时读取被控的状态信息，以及读取这个被控通过哪个长连接服务能被访问到；整个向日葵有多少台主机，这个实时数据就有多少条；每条数据大概也就几百个字节，目前每组服务数百万条记录。这些数据的更新频繁度也非常高，因为那么大量的被控端总是在不停的上下线，目前峰值的时候QPS可以达到万次。

　　其实刚发布向日葵的几个月我们是把它们同时放在关系数据库里的，那个时候主要考虑的也不是服务端的性能问题，而是整个系统跑通，只是我们的数据库后来吃不消了，很快我们就走上了漫长缓存优化之路。

　　3、缓存优化史

　　既然存在关系数据库中不合适，我们就开始用各种缓存技术来存储这种实时数据。

　　3.1 从memcached到ttserver

　　3.1.1 memcached

　　第一代的主机状态数据缓存化，我们把它放在了memcached，整个客户端的登陆过程是这样的（里头略去了各种错误处理及异常以及各种附属架构，比如负载均衡或者备份等）：

　　把状态等需要频繁访问的数据放到缓存后，这个大框架到现在也还基本上是这样，API负责所有跟持久化DB的交互操作，长连接只负责跟memcached的通信，这样也避免了我们的DB有过多角色参与读写；另外这个时候我们只有一台memcached服务器，因为我们算过16G内存大约可以放上亿的主机信息。

　　但这些数据跑memcached真的合适吗？

　　memcached刚刚上线的很长一段时间内系统运行还是很完美的，速度也完全够用，因为数据量以及QPS对memcached来说也还不太大，但后来我们的向日葵用户量发展迅速，主机和在线量都在急剧的上涨；而由于memcached并没有主从同步之类的机制，任一个主机的缓存信息只能存在一个memcached中，而一个memcached其实也就是一个进程，我们没法保证这个进程永远活着，它会崩溃，机器也会死掉，网络也会死掉。

　　在经历了两次memcached崩溃后我们也崩溃了，memcached的数据是完全放在内存里的，崩溃后存在其中的所有主机全部会变成不在线且只能通过重启所有服务器解决，而重启所有服务器意味着所有原先在线客户端都得全部重新登陆一次，这个过程会极其漫长，以小时计的。

　　3.1.2 ttserver

　　我们要改进了，顺其自然的，我们想到了ttserver，ttserver可以在崩溃重启后恢复数据且具备主备同步功能，而丢失那部分数据我们可以在客户端登陆时从DB里自动恢复出来；

　　由于ttserver跟memcached通信协议上完全兼容，但为了避免全局性的灾难，我们在完成多cache服务优化后，新系统很快就上线了。

　　新缓存体系的结构长这样的：

　　完全堆叠式的设计，理论上也是可以无限扩容的，但我们没意识到ttserver几个大问题：

　　ttserver不支持key过期的，需要开启table database模式，并通过lua脚本的方式来实现，但该模式ttserver的运行性能相当差，并且在数据很大的时候出现不稳定的现象。

　　这个不稳定现象我们不凑巧也遇到了：由于它会自动把不频繁读写的数据swap到磁盘，它倒不会像memcached那样容易崩溃，但它会偶尔神经质似的卡；卡到什么程度呢：手工上去敲个get，大概要几百ms才会得到结果；而我们对ttserver做了很多优化依旧于事无补。前两次卡死，重启能解决，但后来，我们不得不把它保存的文件彻底删除才能恢复性能，这不又回到了memcached时代吗？怎么办？

　　3.2 MySQL InnoDB memcached plugin

　　在我们出现ttserver危机的时候，已经没有什么能让我更绞尽脑汁的事情了，天天到各社区调研，某个偶然的机会，我看到了MySQL居然支持memcached插件，这真是个神奇的组合：

　　传统关系型数据库在大数据时代的性能与扩展，离不开内存与分布式这两大主题。

　　在传统的关系型数据库中，Oracle的Timesten，SQL Server的Hekaton，都是选择与内存数据库相集合，但实际上却少有突出的应用场景。而MySQL嵌入nosql ，在性能与管理、分析上达到互补，则是更为有意义的结合。

　　MySQL5.6.6后开始内嵌 memcached 的支持，在MySQL 5.7较新的版本性能大幅提升，有测试表明在48核只读环境下QPS可以达到百万以上。