Zenghui Bao's World

Dynamo是Amazon开发的分布式键值存储系统，它采用去中心化、松散耦合，由数百个服务组成的面向服务架构，只提供简单的键/值(key/value)方式的数据访问接口，不支持复杂的查询。最初用于支持购物车应用、S3服务，Facebook对照其论文实现了一个开源的分布式数据库Cassandra。

今天在压测系统性能时，遇到了一个现象：当短时间发送大量消息(每秒16万条消息)时，内存占用过多(增长到5.4G)，而且之后没有再释放。排查了一下这个问题，找到原因是：muduo中TcpConnection的发送缓冲区增长得太快，而缓冲区是自动增长的，没有自动缩容的功能，导致缓冲区占用的空间越来越大。

监控分为监控进程内部的状态(比如某一时刻接受了多少连接，进程内部某个变量的具体值)、及监控外部的状态(比如进程的cpu使用率、内存占用、磁盘、带宽)，本文只讲监控内部状态。分布式系统中的每个长期运行的服务进程都应该内置一个监控接口，当进程运行出现异常时，通过这个探查通道，查看进程内部的状态，更好更快地确定异常产生的原因。

这是我学习Linux多线程编程、实际编程时 遵守的一些小tips，也算是阅读《Linux多线程服务端编程》的读书笔记吧。

最近在阅读一些开源代码，看到好多项目是用RPC方式(而不是直接用消息传递)来进行模块间的通信，遂思考了下RPC的优缺点。

刚进项目组的时候，各个server之间的消息格式较复杂，有好几个段(字节段)，每个段有bin串、也有json串、C struct，还需要标识每个段的长度、消息的类型等，这使得消息解析的时候很麻烦，要处理各种case。跨平台、跨语言的交互(比如和android交互)就更麻烦，经常要沟通联调好一会，才把消息调通。后来考虑调整一下消息格式，裁减不需要的段，简化交互协议。

一般写服务端程序都需要有一个称手的网络库来帮我们处理琐碎的网络通信细节，比如连接的建立、关闭，读取数据，发送数据，接收、发送缓冲区的管理等，常用的C/C++网络库有libevent，asio，libev，我们项目组使用的是muduo网络库。muduo是陈硕写的，基于非阻塞IO和事件驱动的现代C++网络库，原生支持one loop per thread模型(即reactor模型)，它适合开发Linux下的面向业务的多线程服务端网络应用程序。

好久没写博客了，翻看了下博文目录，最近的一篇文章才是去年10月份写的。今年加入了一个新公司、也要准备结婚，事情变多了，容易产生惰性，导致很多重要的事都搁置了。现在事情处理得差不多，要继续开始我的学习计划。