工作原理
提醒： 请阅读下 [memcloud相关术语定义] (https://github.com/downgoon/memcloud/wiki/%E6%9C%AF%E8%AF%AD%E5%AE%9A%E4%B9%89#memcloud-%E6%9C%AF%E8%AF%AD%E5%AE%9A%E4%B9%89)
mem-client & mem-dns 交互流程概述：
-
AppClient（又名mem-client）启动时，给mem-dns发送Lookup请求（输入AppId）。 -
mem-dns返回 memcached group （术语是“mem-cluster”）。并告诉mem-client以什么频率来刷新mem-dns的解析结果。 -
mem-client给mem-cluster内的所有mem-sharding建立连接（注意：每个mem-sharding包含两个相互备份的mem-instance）。在选择其中一个mem-instance作为Master（通常选择排序在前面的那个），并给每个mem-instance发送心跳。 -
mem-client如果发现Master的心跳失败，就会自动切换到Slave （mem-sharding的另一个mem-instance）。
提醒： mem-sharding之间是双向复制的，测试请阅读 replication-testing
mem-agent 交互流程概述：
-
mem-agent从远程软件仓库下载memcached相关软件包。目前存放在github.com上（也可以存在mem-dns上）。如果已经下载到本地了，就不会再下载。 -
mem-agent下载完相关软件包后，就会自动执行安装过程。 - 安装完成后，需要手动执行
mem-agent start操作，并指定相关参数（比如侦听端口），以便启动一个新的mem-instance。需要提醒的是“一个mem-host可以运行多个mem-instance”，另外如果需要双向复制的，还需在另外一台机器启动它的mem-peer。 - 启动后，
mem-agent会给mem-dns发一个注册请求，把刚启动的mem-instance添加到mem-dns中（mem-dns会把它们加入mem-instance pool）。
mem-alert 交互流程概述：
-
CaptureScheduler启动时向meta-server（又名mem-dns）发送scan请求。 -
meta-server返回mapping-list（每个item是从appid到cluster集群实例的映射关系）。 -
CaptureScheduler迭代mapping-list，并给每个AppId生成一个CaptureWorker，由CaptureWorker负责周期性的巡检该AppId下所有mem-instance的可用性和数据采集。因此创建CaptureWorker就设定了巡检周期和告警规则AlertRule。 -
CaptureScheduler给AppId下的每个mem-instance发送stat命令（memcached的原生指令，用于采集memcached当前运行状态信息）。 -
memcloud集群（隶属具体AppId的）返回运行统计信息。 -
CaptureWork把运行统计信息入库到TSDB（具体实现可以是InfluxDB，OpenTSDB或者MongoDB循环库）。 -
CaptureWork写TSDB，同时用AlertRule告警规则检查。 - 告警规则，如果发现异常（比如系统挂了或者数据波动剧烈），把异常信息推送到
AlertNotify平台。 -
AlertNotify先把异常信息（告警事件）入库。 - 入库后，发送短信给用户。短信中携带了一个详情链接。
- 在详情页面可以点击ACK按钮，表示告警知道了，正在处理。
-
AlertNotify收到用户ACK反馈，把告警事件状态修改成“已通知到，正在处理”。