kvdb之路

kvdb之路:

1.一切从客户端开始，开始接手客户端，参照着淘宝的tbstore开始了socket编程之路。渐渐熟悉和修改出了自己的storeSocket,然后随着讨论的深入，加上了连接池，连接池使用apache pool管理socket,apache pool负责管理socket的创建、保持一定的连接数，最大连接数，销毁，检测连接正常。因为客户端需要面对多台服务器通信，每个服务器又有多个socket连接，所以又设计出了Server 和全部机器状态表SAT，当某台Server的某次通信失败，并且尝试3次后都不能正常通信（根据错误情况，如果是获得确定的信息，第二次重试直接获取另一台服务器通信），设置该Server在SAT信息为不可用，并在后台开启进程进行检测。Server对象也被另一个连接池管理，维护Server列表，持有SAT，对外封装业务接口。最终独自完成了客户端代码的开发。期间讨论出我们的设计协议（两个人通信的基础）

2.kvdb0.1，完成了客户端代码，开始使用erlang构建与sp的通信代码，最初的spconnect.erl，与spserver通信，至2010.10月份还依旧能看到以前的注释。然后是wp，接手服务器sat模块熟悉和重构sat，设置sat状态存储结构和存储方式，写wp模块。最后完成了协作0.1上线。

3.kvdb0.2，0.1上线后维护着系统，3个月 的使用中逐渐出浮现一些小bug，如：日志格式、后台的错误、特殊字符的存储不正确（存储的时候很多是富文本）、 服务器状态的新需求，借鉴java的log4j，在研究了erlang-log底层的代码后，并随着erlang 的学习，对kvdb增加了日志模块。研究jdbc/mysqlclient，将mysql对数据的编码/解码的代码添加进了我们的客户端。独自完成开发上线，成了kvdb0.2版本。

4.渐渐的，团队开始重新关注kvdb，讨论增量的只增不改数据的设计，期望更进一步加速性能，并自己实现数据的同步。放弃原新架构设计（两台mysql主主复制）。这次负责包协议的修改，负责wp/rp/spclinet的修改，以满足新架子的工作。最多的时间还是发在如何处理无人接收的消息。erlang是进程间通信的语言，程序的功能完全是依赖于进程间通信。根据历史的错误问题，总是有会莫名的进程消息报错。a进程和b进程通信，b进程又和c进程通信，然后a进程会报错，描述收到c进程的消息。这是还是幸运的。不幸的是，代码中充满了同样的返回消息反馈，有时候根本不知道a进程报错时，消息是从谁那里接收过来的。整体的现在就是a进程接收了不属于自己的消息。问题的定位变得很困难，根不本知道代码出了什么问题。虽然对使用方，还没出现功能上的影响。但不容易维护了。逐个跟进代码，将容易出问题的几个模块的消息反馈加个自己的独门标识。让问题变成幸运，明了。在这个版本中，我们追求的是速度，参照以前前台优化的经验，逐功能逐句的跟踪每个代码的执行速度，socket与后端sp通信基本上要有时候是0.5ms有时候是1.5ms，有时候更高，逐个去看代码。该版本的设计初中就是性能之路。但整体架构设计还是过于追求性能，牺牲太多，加上代码的不健壮，后期维护不够。该版本命名0.3。

  5.kvdb0.6,去年年底，鉴于0.3版本，感觉我们太过于追求性能，又因为每一个应用需要部署一组服务器。在老常的倡议下，开始了重构代码之路。合并了rp/wp，新模块叫ap。重新定义了新的通信协议，协议版本0.3.   0.6版本的kvdb兼容0.1 0.2版本的代码。因为当前的kudb、点评存储和一些应用在使用kvdb0.1/0.2。放弃了对kvdb0.3的兼容，让0.3只服务于行业化 。为满足新版本和兼容的需求，开始重构客户端。服务器端负责再次重写了sat（服务器状态表），设计ap。随着进度的发展 ns+kvdb0.1/0.2去满足kudb和点评存储的稳当方案被变更成ns+kvdb0.6去满足业务需求，重点移到了客户端的变化，开始思考如何设计客户端结构，满足更多的需求，按照职责，将代码分离成了业务接口层、服务驱动层，业务接口层提供不同驱动的组合满足业务。服务驱动层只负责与服务器的数据通信，无业务耦合。在提供基本的应用接口版本之后，最终由应用方负责写业务接口层代码。将来kvdb的开发人员负责保证数据的正常通信做到了松耦合，当有新的服务时，添加新的驱动接口，业务方开发人员自己去配置灵活使用。