付费并发服务器开发的心得体会

即将从迅雷离职了，虽然有点舍不得，但是既然做了决定，就会坚持。

一年多的时间，我很感谢迅雷给我的机会，让我刚来就能负责迅雷看看付费频道的后台开发，接着又把看看无线的整个后台交给我维护，敢于用人，因人而异的思想让我受益匪浅。

刚来的3个月其实是个挑战，因为这段时间里，付费频道（vip.kankan.com)从无到有，从架构到上线。

为什么选择C++？

诚然一些脚本如Python，写CGI也是很方便的，维护和扩展也非常方便，但是如果并发量大（如用户信息获取，几乎在每个页面都有），实时性安全性高（如支付逻辑，几乎不能有错），可跟踪可调试的服务器，似乎只能选择C/C++了。

为什么不用现成的服务器？

在nginx上做开发，如taobao一直推崇的模块开发，对于熟悉nginx的人应该可以很快上手，但是我还是没选择它，因为nginx其实也有一些解决不了的难题，后期将有文章专门论述。

付费项目将会有哪些难题?

1.产品库的更新（如新增的产品，修改的价格）必须实时在页面上体现。

2.用户购买的价格因人而异，因为可能有很多种身份，如会员，套餐，包月等，用户的身份也会随时变化，如套餐过期等。

3.跨服务器的调用，如和用户信息服务器的交互，对并发性实时性要求很高。

4.并发性与实时性。

开发起来有哪些工作需要注意？

根据以往的经验，数据库的交互开发会占用很多时间，而且sql语句也会千变万化，为了节约开发时间，专门开发了一个工具，根据数据表生成好data object,并且交互层封装成一个类，再把所有的请求数据放进data manager里。

产品库变化快，有可能会碰到一个connection 已经请求得到一个 produt info 指针，但是产品库已经更新了，内存也释放掉了。信息缓存这一块的内存管理上其实很重要，我的做法是将产品库根据更新时间分代，每一代有一个引用数ref，ref的增加与减少放在request 生命周期中。根据引用数来控制，就保证了内存实时更新与安全了。

内存管理，我们知道内存的分配和使用过程中会触发很多缺页中断，对于交发量大的服务器，内存管理其实很重要。

与nginx的做法相似，我将服务器的内存分成connection,request,busi,三个等级内存池，由它们的生命周期来统一协调内存管理。

与前端的交互协议设计也是一块重点，从早规划，封装成一个统一的json接口，会让后面的工作轻车熟路。

总体来说，服务器的开发其实很累人的，如果三个月的时间里我没有完成工作，估计我就只能打个酱油了，各种加班，现在回想起来，还是心有余悸。不过当我看到产品上线，给公司赚线的时候，心里还是很欣慰的，为它付出的努力也是值得的。

接下来的这段时间，我将会整理这些年对服务器开发的一些心得。