2016-04-30
- http://www.vimer.cn/2016/03/三省吾身.html
- 网络编程的细节问题，比如 epoll的水平和边缘触发、
TIME_WAIT的原因与处理
- 什么redis可以做到10w/s的访问？网络层是怎么实现的？存储是怎么实现的？
- 服务器框架使用的是c++和python.
- 为什么用c++？因为连接层的gateway server要求性能非常高，所以我们使用c++和epoll来完成
- 那为什么又用python？因为业务层代码使用python开发会更快，并且业务层代码的瓶颈不在语言本身，而在于架构设计
- Linux下进程绑定多CPU运行
2016-04-27
2016-04-19
2016-04-18
2016-04-07 周三，家，晴天
2016-03-27 周日，家，晴天
- 思考优化数据模型
- 创建object时就根据节点书目，创建好所有的节点
- 创建object时就预先创建1个或N个节点(根据业务场景，大部分的更新操作需要的节点)
记录整颗树的节点数node_count, 后续如果需要继续操作节点且节点数超过了预分配的
节点数，就翻倍申请，最终节点数要取翻倍和node_count的最小值.
- 数据模型提供了如下功能
- 基本的编解码
- 写操作：在客户端，用户通过节点给各层的节点的子段填充数据; 在服务端，提取
二级索引数据，更新二级索引表，最后把整个object写入存储空间。
- 更新操作: 在客户端，用户通过节点给相应的节点的子段填充数据; 在服务端，提取
原有数据，然后应用更新操作，汇入写操作流程。
- 读操作: 在客户端，通过key读取到数据后，解码数据，用户调用其他接口读取字段值.
- 性能热点与优化建议
- 问题：写或更新操作存在大量的内存申请操作
- 优化：根据业务场景，预先分配空间，如果数据量不大(比如少于1MB)，可以考虑直接
在栈上申请空间，如果数据量较大，就预先在堆上申请。
- 问题：在编码的最后节点需要作内存调整和拼接
- 优化：由于目前内部采用的是多个内存块保存数据，是否使用可以发送多块内存的RPC??
- 问题：接口操作都先拿节点，然后再给字段填充数据. 造成要为每个节点申请内存，并且要保留。
- 优化：如果用户的本意只想作因此字段赋值，后续不会再操作了，那么根本就不需要
给该节点申请并保留内存，只需要在栈上申请即可。
- 问题：用户没法对多个字段填充数据
- 优化：提供接口实现，但是如何高效的解析用户的多个字段数据呢? 既要友好也要解析高效.
比如 set_multip_fields(object_t obj, const char* node_name, field_value_t* values, uint32_t count)
这样也兼容用户只想设置一个字段的情况。从性能上来说，只要用户一次把一个节点
的字段填充完毕，就不会带来性能上的问题. 而对于读操作，也可以使用同样的参数。
- 优化：对于数组节点，用户常用的操作有：追加一个节点，填充数据到相关字段上。
再添加一个节点，然后填充字段数据; 删除某个节点;修改某个节点的数据; 这是都使用
到同样的数组节点，这时，就要保留该节点，因为没有办法把所有操作揉合到一起.
2016-03-18
2016-03-17
- optimize performance for data accesse
- change std::string to character of array
- Not use STL containor, such as vector, string, map and so on.
2016-02-27
- upgrade jekyll 2.5 to 3.1.2
- 因为github升级了jekyll，导致原来的语法高亮设置有问题，blog无法正常高亮。
gem update jekyll
- 由于国内网络问题，不能直接使用官网的源进行升级，必须更换
gem sources --add https://ruby.taobao.org/ --remove https://rubygems.org/- https://ruby.taobao.org/
- git配置
2016-02-26