张小峰 Oray技术总监

简介

张小峰专注于高性能网络服务架构，15年C++网络应用开发和团队管理经验；在DNS架构、C++网络通信技术、各操作系统API交互、图像处理、加密算法等领域都有着深入的研究；在Oray技术团队中负责所有产品的网络服务及图像底层架构设计与开发；带领团队先后研发了多款花生壳、向日葵远程控制软件千万量级的产品，从事其中的结构设计与关键技术攻关。是Oray技术团队的领头羊与灵魂人物。

应用背景介绍

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

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

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

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

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

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

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

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

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

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

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

1、 主机鉴权信息

2、 主机在线状态

3、 如何连接主机

其实刚发布向日葵的几个月我们是把它们同时放在关系数据库里的，那个时候主要考虑的也不是服务端的性能问题，而是整个系统跑通，只是我们的数据库后来吃不消了，这一段经历不长，说真的也没啥好讲的。

缓存优化史

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

从memcached到ttserver

memcached

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

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

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

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

ttserver

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

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

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

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

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

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

MySQL InnoDB memcached plugin

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

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

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

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

借用下MySQL官方的结构图：

我们先来看一下memcached plugin的安装：

下载mysql5.7.17 源码包：

wget http://cdn.mysql.com//Downloads/MySQL-5.7/mysql-community-5.7.17-1.el6.src.rpm

因为是一个插件，开启memcached plugin功能，需要在编译安装时添加：

-DWITH_INNODB_MEMCACHED=ON

cmake .

-DCMAKE_INSTALL_PREFIX=/usr/local/mysql5.7/

-DMYSQL_DATADIR=/data1/

-DWITH_INNOBASE_STORAGE_ENGINE=1

-DWITH_PARTITION_STORAGE_ENGINE=1

-DWITH_INNODB_MEMCACHED=ON

-DENABLED_LOCAL_INFILE=1

-DWITH_READLINE=1

-DMYSQL_UNIX_ADDR=/tmp/mysql5.7.sock

-DMYSQL_TCP_PORT=3306

-DEXTRA_CHARSETS=all

-DWITH_EMBEDDED_SERVER=1

-DWITH_DEBUG=1

-DWITH_BOOST=../boost_1_59_0

安装启动后执行配置：

mysql> source /usr/local/mysql5.7/share/innodb_memcached_config.sql

启动memcached插件：

mysql> install plugin daemon_memcached soname "libmemcached.so";

关闭memcached插件：

mysql> uninstall plugin daemon_memcached;

memcached plugin相关配置表：

innodb_memcache.config_options--配置分割符、引用符

innodb_memcache.from cache_policies--根据需要设置缓存策略

innodb_memcache.containers--设置表结构：key、value大小，过期时间等

（编辑：厦门网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!