（PS开始应用《暗时间》里提到的理论，将skynet用自己的话来总结并写下来，这样能充分思考并转述为自己的记忆线索）

一、skynet设计的理解

（一）单个skynet节点

（1）愿景

    充分利用多核。最初想法是多进程。像咱们nodejs里多核就只能是多进程了，因为每个nodejs进程是单线程的。

    多进程是遵循unix设计哲学，工具链形式，分拆进程的形式来分拆模块，减少复杂度和耦合性，方便编程及维护。

    后来云风他们发现lua做为嵌入式脚本，写逻辑时很好用的，反正如何都要用lua，而且lua提供了沙盒，这样多进程可以变为单进程多个沙盒，这样综合了多进程和单进程多线程的优势。多线程里共享资源，在同一进程地址空间，访问更高效。

（2）核心功能（门房？）

    很精简，仅解决一个问题。

    skynet里不实现具体游戏逻辑，后者些放到一个一个动态库里（so文件）。skynet将这些so注册到自己里边，每个so一个永不重复的id，类似于数据库的autoincreament。看描述这个id是skynet自己运行时当次维护的，而不是模块配置好终身的id。模块的永久有效唯一标示为名字，skynet提供了名字服务，可以给每个模块取一个易读的名字。

（3）核心不解决什么问题

    skynet主张所有服务在同一OS进程协作完成。核心里就没管跨机通讯，单个服务的崩溃和重启也没管，云风表示这些应该由上层处理，他有责任暴露错误，而不是隐藏。

    这个设计的原因，游戏和操作系统不一样，操作系统默认不信任任何进程，各进程崩溃什么的不应影响其他进程，所以某个进程挂了，他就安葬它，而其他进程美好的生活。单游戏是为玩家服务的，某个环节出错都有可能造成玩家利益混乱，所以那里错了就整个流程（服务器）挂掉吧。没有必要让出错模块被隔离开，而其他模块却继续提供服务导出未预知行为。

    上边说的东西应该上层考虑，使用lua的沙盒就能做策略隔离。

（4）skynet运行时逻辑流

    skynet负责且只负责将一个数据包从一个服务发送到同一进程的另一个服务里。发送服务直接调发送API，skynet收到数据包后，调用接受者服务的注册的callback，即发给了接受者服务。

    skynet保证在各模块初始化时、每个独立的callback调用时，都是相互线程安全的。这样编写服务的人就不需要考虑多线程的任何问题了，只需专心处理给他的一个个数据包。

    PS：天龙的场景lua有点像这里的单个服务。不知天龙的跨线程切场景情况在这里也可以给简化为单线程？（回头看源码再研究这个问题）

（5）消息调度

TODO

（6）gate和connection

TODO

​

（二）skynet集群

    集群里最多支持255个skynet节点，每个skynet节点有一个id，成为harbor id。这个id是集群层面指定，可以人为分配，也可以由一个中央服务器协调分配。

（1）集群间通信

    skynet核心层纸负责在往外发消息时在source字段上加上自己的harbor id。而集群间的通信，是由单独的harbor服务来做的。skynet将是往集群其他节点发的消息，就转发到harbor内。harbor会跟集群内跟自己结识的skynet的harbor简历tcp链接。harbor把消息发给目标harbor。

    harbor间的通信为单向的tcp管道。

    master服务来同步全局的名字服务。每个skynet都会知道其他节点上装配了哪些服务，好路由过去。

（2）组播

    TODO

一、回顾

    之前的登陆流程在这篇里。之前的登陆流程简述：

（1）先检查是否同服已登陆，是则两个链接都踢掉，否则进入下步；

（2）判断是否异服已登陆，是则告诉异服踢老链接，随后踢自己这的新链接。否则进入下步；

（3）当前服务器登陆相关流程走完后，向玩家在线列表汇报（写入这个玩家登陆的服务器id为我）。这时的汇报写入为redis的CAS操作，为了检查是否发生了那篇里介绍的同账号瞬间多起登陆事件。CAS操作成功，本服链接登陆完成，做后续操作。否则CAS操作失败，表示瞬时登陆的异服同账号的另一个链接的登陆流程走的快，已经完成整个流程，包括汇报进在线列表。这时的处理只用将慢拍的本服链接关闭就行了。

二、存储架构变为redis+mysql后的问题

    现在玩家上线时需要从mysql加载玩家离线数据到redis，需要考虑这个数据加载放到上边登陆流程哪一步里。

    首先数据加载有可能会失败，如果数据加载出问题，就不能让该玩家登陆。

    如果放到（2）（3）之间，就是redis的CAS之前，这样瞬间同一账号多起登陆都有可能开始进行加载数据步骤，而处理的快的那个客户端就有可能汇报登陆完成之后立即玩游戏并更新了自己在redis里的数据，处理的慢的客户端还这时还在将mysql的数据往redis的加载，会覆盖快的客户端更新的数据。

    如果放到（3）里redis的CAS之后，数据加载失败，就需要回退CAS的操作。

    可见第二种至少可以保证数据正确性。这种情况抽象下，就是第一种里没有提供事务操作的回滚（慢客户端覆盖数据后发现干了坏事却不方便回滚自己的破坏）。

    （2）这个操作当时是为了区分异服登陆并玩游戏很久了和瞬间多起登陆这两种情况的。现在想想这两种情况的处理统一为直接踢掉新旧两个链接也没什么，毕竟瞬时登陆的情况不多。

三、新流程

    根据上边的结论，新的流程为：

（1）先检查是否同服已登陆，是则两个链接都踢掉，否则进入下步；

（2）向玩家在线列表CAS报告自己登陆。如果失败告诉异服踢掉该账号老链接，自己这边踢掉该账号新链接即可。成功则进入下步；

（3）加载数据，成功就进入正常游戏流程。加载失败，就去在线列表里清掉自己。

一、纯redis集群

    如果redis不止做cache，也做持久化，那就得好好算算我们的业务规模需要多少台机器来支撑。1000w注册玩家，每台机器16G内存（为了保证效率取3/4为可用，即12G）。

    如果每个玩家1M数据，总约9765G，不算热备，需要814台机器。每台机器存储1.2w人。

    如果每个玩家16k数据，总约153G，不算热备，需要13台机器。每台机器存储77w人。

    如果每个玩家1k数据总约9.5G，不算热备，需要1台机器。每台机器存储1000w人。

    注册玩家会越来越多的……

二、mysql做持久化，redis做cache

    只说存储，一个mysql支持几T数据没什么问题。例如上边1000w注册玩家，每个玩家1M数据，总数据近9.5T，存一个mysql足够。但是如果高峰在线玩家并发到100w，需要将大部分操作规划到redis这个cache上。否则mysql仍然因磁盘IO太多吃不消。

（一）与纯redis集群相比的劣势

（1）好友需要看离线玩家的信息，而离线玩家在mysql里，如果频繁？

    把离线玩家可能被别人查看的信息不存mysql了，改用redis做持久化。

（2）GM工具改玩家消息，需要改mysql和redis的cache里。会不会容易出问题？

（二）优势

（1）redis只做cache集群了，用twemproxy管理就行了。如果redis做持久化，还是需要自己来分片，且早期就要规划好。

（2）单个玩家的数据涨到1M的时候，总用户涨到2000w~3000w，再加两个mysql。

三、redis做cache+热数据持久化，mysql做冷数据持久化

    这里其实就是将二里边的每个玩家的部分很热的数据从mysql移到redis里做持久化。但是玩家在线时，他的数据基本都算是热的。所以这个方案不是很好设计。

最后、参考

1. redis官方关于分片的文章：http://redis.io/topics/partitioning

2. twemproxy文章：http://antirez.com/news/44

一、背景和目标

    当年大三的时候写了个五子棋世界，就是qq game那种大厅-房间-桌子（我只有简单逻辑的五子棋）。毕业后一直想找个时间来重构它，后来有次下决心看了下代码，有点儿不知所措，你懂的，：D，还不如重写。

    现在对go很感兴趣，准备用go来实现以前的开源梦。就先已以前的五子棋世界那种休闲游戏平台来开始练手吧。

    目标暂时不定的太大，基本实现大厅-房间-桌子-游戏就行了，慢慢重构慢慢完善。

二、服务器架构

    基本架构参照之前给公司项目做的架构。当架构有改变时，及时修改这篇博客，或者新博客与这篇相互引用和注解。

    不同的部分，加个大厅，大厅里显示房间状态，这样玩家就自己选择闲的房间去玩，这样就不需要做负载均衡的算法了。

（一）账户系统

    游戏自身不做账号密码这种用户系统，只用第三方的账户，如微博账户等来连接到我们游戏。或者更简单点，这块儿只模拟下微博等第三方用户系统的登陆了。

    第三方账户连接到我们游戏，我们本地只由自增长的uid生成器来生成一个int的uid即可，将第三方的platformUid和我们的localUid做个关联映射。

（二）大厅

    大厅可以做成短连接，玩家选择游戏及房间的时候才去大厅刷新下当前的各房间负载情况。

二、客户端

    用walk。（待详细规划）

一、玩家离线

    由于离线的状况多，常见的玩家自己拿自己的账号的离线，也有自己的账号在多个设备来挤掉线，还有就是被非法的人使用时的挤掉线。这里应该将玩家理解为一个账号，下边尽量用账号来表述。

（一）网络断开或者主动离开游戏

    这时玩家所在的服务器在玩家net.close时加入向通信redis汇报的逻辑，即通信redis里删除这个玩家的在线纪录。

（二）同服重复登陆时的kick

    首先肯定要踢掉之前登陆的链接。因为同服时新旧链接都在这个服务器上，逻辑上简单，允许新链接的登陆比较好处理，但是后边有其他考虑。

（三）异服登陆时的kick

    首先也是踢掉之前的登陆。需要在之前登陆到的服务器将该账号的链接断开并整理数据存储之后，才能允许在新的服务器登陆。

    旧服务器清理完该玩家后，向通信redis报告删除该账号的在线状态。新服务器需要知道玩家已经在旧服被kick完了才可以让玩家登陆。刚才同服时提到的允许新链接立刻登陆的问题，这里就变的比较不可控了。美好的过程是，新链接接入后挂起在新服，等异服踢完后，继续做新链接的登陆操作。但是这需要新旧服之间的同步逻辑，需要将新服玩家做个状态机为维护这种挂起或继续登陆状态。另外还要考虑这个期间玩家又在另一个服登陆。要考虑的东西很多……

    还有一种有问题的处理方式，即新服只是向老服发送踢人指令，新服自己却马上进入新链接的登陆操作。这样的问题是，即使业务逻辑简单到不会发生数据不同步问题，但登陆操作不会一定成功。新服登陆完向通信redis报告玩家在线，旧服踢完要向通信redis报告玩家离线。这两个操作异步时，如果旧服的离线报告在后，通信redis上就会错误的记录账号当前不在线……

（四）总结

    最终重复登陆问题简单处理方法：账号登陆时，只要检测到该账号同服或异服已登陆，先将旧链接踢掉，再将新链接断开。就给玩家一个提示“账号已登录，请稍后重试”，让玩家自己来多操作几次，直到旧链接被踢完。

二、同一账号的同瞬间多起登陆事件

    ​上边重复登陆的检查还有一种情况不能防止，就是瞬间的多个客户端用同一账号登陆。同服时由于nodejs的异步，异服时由于天然异步，检查该账号是否已登陆与将当前链接成功登陆并向通信redis报告这些操作不具原子性。

    ​所以在最后向通信redis写入上线状态时再次判断是否已登陆（即判断是否被瞬时并发的另一个客户端的登陆给标记为已上线了）。redis里用hsetnx代替hset，前者在数据已经被设置时操作失败。

​

PS：

    刚接触不久或者本身逻辑就复杂的东西（例如分布式）很多思考的结果不及时记录的话，后边容易忘记当初的理由，导致需要冗余的重复思考。所以现在博客写琐碎些，记载些细节的思考。

一、背景

    项目开始后，先敲定了大体可横向扩展的集群架构（这是个美好的期望），然后开始编写单进程的服务器底层和逻辑，让前边几个迭代周期的逻辑内容配合客户端跑起来了。

    接着就是将单进程的架构扩展起来，设计上细化下架构的扩展。已写在前篇《休闲手游服务器集群扩展思考》里。最近的两周在将之前单进程的服务器架构里部分模块扩展为支持这篇随笔里提到的集群架构。

    实现的过程中碰到的一些需要仔细设计的细节，原则上还是K.I.S.S。

二、全服玩家在线状态

    逻辑服务器集群的负载均衡算法还没实现。先只扩展玩家间的同服通信为异服通信（通过redis的pub/sub，以下将这个用于通信转发的redis简称为通信redis）。

    问题链：（“-->>”引出的下个问题被当前问题所依赖）

        通信发起方需要知道目标方在逻辑集群里的哪个服务器上 -->>

        玩家登陆和退出时往通信redis报告 -->>

        登陆时检查账号是否注册到我们的游戏，否就注册 -->>

（一）登陆和注册

    玩家拿到用户系统的账号来登陆我们游戏服务器。游戏服务器拿client给的这个code再去用户系统服务器做验证，通过后继续。

    检查账号是否在我们游戏注册，如果没有则注册上，映射出游戏服务器上的一个local uid。这里需要检查玩家是否在游戏注册了，所以需要一个platform uid与local uid的映射表。这个映射之前单进程服务器时与其他角色数据放在相同redis上的，现在移到全局类的redis上（以下简称全局redis，暂时是将通信redis和全局redis放一起的，等以后看压测和线上反馈再做演变）。另外用来本地注册生成local uid的自增长id也移到了全局redis上。

    ​检查完注册，得到local uid，先看是否在本服务器登陆了，否则再向通信redis查看是否登陆在其他服务器。如果已登陆，则踢掉之前的登陆。之前单进程只有同服重复登陆踢人，现在多个异服重复登陆的踢人操作。

    登陆成功向通信redis报告local uid和所在的这个logic服务器的server id。另外退出时也向通信redis报告，注销掉这条记录。

（二）异服通信

    每个逻辑服务器都与通信redis建立用于pub/sub的链接，各逻辑服务器有自己的频道。

    异服上的玩家通信时，从通信redis拿到目标玩家所在server id，让后向目标server所对应的专有频道pub数据即可。

三、压测工具

    加了这个集群扩展后，底层测试只是单元测试是不够的。反正要压力测试工具迟早要写，就先写了简单版的压测工具，来做异服通信的自动化测试。

    压测工具开始的想法挺多的，后来抛弃了一些短期不好实现的想法。现在就简单的，一个client一个Client struct，这个处理client的通信发送接收。做相同动作的client为一个Group struct。每个动作为一个Rule struct，里边组合好收到什么包后做什么事情，或者直接发些什么包。

    c++端游压测的每个Rule动作一般用lua来写的，比较方便，我们这个压测工具用go写，rule暂时也用go写，也不麻烦。

    感慨下，这种并行的应用场景，go的编程思维与具体写法比node.js更适合c/c++出身的程序员。

一、目标

    能横向扩展，架构要简单，能做到负载均衡，避免单节点负载太轻的资源浪费。

二、数据存储的DB集群

    ​数据存储类型有多种。

（一）非交互性的个人数据

    ​可通过简单的id分段。id为1~10000的玩家个人数据存储在db1，id为10001~20000的玩家个人数据存储在db2，以此类推。

（二）交互性数据

    ​如好友关系等。

（1）如果好友关系可以为单向，那么可以将关系存到个人数据里。

（2）如果好友关系不能为单向，那么需要保证每条关系保持在要么没有，要么两人都认同，记数据上一直，互相有关系。那么需要保证相关的关系操作的一致性。这样可能只保存一份每两个人之间的关系，k-v存储时需要方向查找，不知是否能实现。

（三）全局数据

    ​如全局排行榜之类的。这种放在单独的库里里，专门做全局数据的存储。当到一定规模时，按全局数据的类型再分库。

    ​家族、帮会等，也放单独的库里。如果需要扩展，再按家族id、帮会id来分库。

三、逻辑服务器集群对DB集群的访问

    ​DB集群的路由规则配置到逻辑服务器的config里。当需要热扩展DB时，启动新DB后，给各logic服务器发送GM指定，reload路由规则的config。

    ​DB集群路由规则的config，可以放在一个公共地方，各logic服务器接到GM指令后，去公共地方拉取新的config然会reload。

四、逻辑服务器集群

    ​为了架构的简单，可以每个逻辑服务器进程上都有所有逻辑，扩展时，以扩展逻辑服务器进程数量来达到。

（一）各逻辑服务器上玩家分配

    ​逻辑服务器集群之间的交互。如果逻辑服务器的使用，也像个人数据存储的DB那样id分段——只让1~10000的玩家登陆logic1，10001~20000的玩家登陆logic2时，这很简单，但各id断的玩家活跃度不定的，做不到负载均衡啊。

    ​所以是根据当时的负载情况，来推荐玩家登陆闲的逻辑服务器的。这样需要有个全局映射，知道哪个玩家登陆在哪个服务器上。可以将玩家当前所在的服务器id记录在该玩家的个人数据所在的db里。

（二）逻辑服务器间的通信

    ​目前项目持久化使用redis，最快出东西，就先考虑redis的优势。

    ​逻辑服务器间的通信，通过全局数据存储的redis来做pub/sub转发吧。

    ​redis的pub和sub的实时性不够时，​将有实时性需求的玩家都转到一个专门做强实时性的特殊逻辑服务器。

五、PS

    ​公司的项目是Node.js+Redis，业余时间打算用Go写个服务器引擎。

    ​这篇考虑发到精华区，可以得到很多的批评建议。

一、node.js能做啥

    http://www.infoq.com/cn/articles/what-is-nodejs

二、杂项问题

1. http的长连接是不是也是只能req/rep模式，能实现服务器端push吗？

    http的长连接即HTTP keep-alive（HTTP1.1里加入），这个原生的只是为了更少的建立和关闭tcp链接，可以减少网络流量；因为已建立的tcp握手，减少后续请求的延时等。这个http长连接不支持全双工通信。

    http实现“服务器推”的技术，一是借助客户端Flash XMLSocket或者Java Applet套接口来实现；另一种是comet技术。（还有一种遭罪的客户端以一定间隔向服务器发出请求的轮询就不提了）

    comet有两种：

        （1）基于AJAX的长轮询（long-polling技术）

        （2）基于 Iframe 及 htmlfile 的流（streaming）方式

    这两种方式看描述已经离手游服务器差远了，就不去招惹它们了吧。

2. 大规模网站的架构？怎么做到水平扩展的？

    网站的需求跟游戏不一样，网站都是http就够了，req/rep即可，没有交互等广播同步之类的复杂状态。

    （pomelo里表示游戏的业务模型很难做到传统网站那种无限水平扩展）

3. websocekt是什么？

    html5开始提供的，为了使浏览器和服务器间进行全双工通讯的长链接协议。websocket协议本质上是一个基于TCP的长连接协议。与传统C/S长连接的区别在于，websocket链接开始时的握手协议，客户端首先要向服务器发起一个HTTP骑牛，这个请求和通常的HTTP请求不同，包含了一个附加信息"Upgrade:WebSocket"表明申请协议升级，服务器回应后，即握手完成，websocket链接建立起来，双方自由通信，直到一方关闭链接。

    websocket相对于http的优点，除了全双工通讯，还有服务器与客户端交换的header信息很小。

    websocket与传统socket的区别，前者有帧协议，不需要上层做拼包了。

4. redis可以直接搞集群吗？

    数据量太大时，redis的持久化会影响性能，解决方案时用个slave专职做持久化。另外redis容灾和传统web应用的减压，就开多个slave，用于分担读的压力。

    当库到一定数量时，可以用分库分表来水平扩展。 

5. node.js能用c++扩展吗？

    v8和node都是c++写的。

三、网易pomelo能干些啥

    分布式服务器，方便扩展。另外实现了很多游戏常用模块，如aoi等。

四、公司的node.js框架有哪些不能做的

1. websocket实现了吗？

    实现中。

2. 方便分布式扩展吗？

    貌似没有pomelo那么方便。 

五、总结

    ​node.js做手游服务器的开发还是挺方便的，pomelo已经做很多事情……

N、参考

1. Comet：基于 HTTP 长连接的“服务器推”技术：http://www.ibm.com/developerworks/cn/web/wa-lo-comet/

2. WebSocket：http://zh.wikipedia.org/wiki/WebSocket

3. 使用 HTML5 WebSocket 构建实时 Web 应用：http://www.ibm.com/developerworks/cn/web/1112_huangxa_websocket/

4. pomelo：https://github.com/NetEase/pomelo

5. HTTP长连接：http://www.blogjava.net/xjacker/articles/334709.html

6. Redis复制与可扩展集群搭建：http://www.infoq.com/cn/articles/tq-redis-copy-build-scalable-cluster

一、简介

    这个项目刚起步，将来有可能会演变为公司的服务器框架。博客里暂且称呼为X项目。

    语言为c++，之后将此服务器的设计演变尽量记录下来，为一个系列，以“X项目C++服务器”为统一标题开头。

二、架构设计

（一）多进程通信方案

    zeromq

（二）协议方案

    protobuf 

（三）存储

    redis

（四）脚本

    luaplus

（五）日志

    glog

三、自动构建部署

    自动构建等为敏捷开发提供保障。

    之前经历的那些项目（其中包括业内比较有名的2个大型项目）在自动构建部署方面基本为0，开发效率不高，这次新项目准备从一开始就做这方面的准备。

（一）单测

    单测框架考虑google的gtest。

一、需求背景

    之前介绍过我们项目的架构，由于历史原因，架构演变成as<-->java<-->php这样，java与as通过tcp长连接通信，java与php通过两条http通道来通信（java与php各自有个http server，并各自作为对方的http client，java转发as以前的post给php；php需要跨session推送或者广播时变为http client向java的http server做post）。

    这之前的架构是as的功能逻辑大部分直接与php进行http通信。

    项目的目标是慢慢将php部分写的糟糕的已有逻辑（例如帮派这种交互和广播同步比较多的）改到java服务器上。项目人员配备跟不上，所以不能一下子全转了。

    如果用之前的两条http通道来小步快跑式的移逻辑，就需要再封装这两个通道之间的通信，费时间还不一定好使，所以我们需要一个java直接调用php的技术。

    goole了解后，最终决定使用PHP/Java Bridge。 

二、PHP/Java Bridge

（一）示例

CallPhp.java

java-bin/data/php/gate.php

java-bin/data/php/function.php

output

（二）注意事项

1. 由于是java调用的php，所以php里当前工作路径变成了java的。

2. FileReader加载*.php文件之后ScriptEngine.evel(FileReader)的耗时大概为230+ms，StringReader时为180+ms，速度都不咋滴，但是这不是我们项目急着考虑的问题，之前的http方式也好不到哪去，优化留到以后再说。

3. php的解释器运行路径配置：-Dphp.java.bridge.php_exec=。

三、相关资料

1. 官网：http://php-java-bridge.sourceforge.net/pjb/

2. 符合java调脚本标准的调php示例：http://php-java-bridge.sourceforge.net/pjb/examples/source.php?source=PhpThreads.java


ps：2013年1月18日我在CU的博客

一、优势

（一）相对于其他k-v数据库的优势

1. 包含复杂数据类型，例如Strings\Lists\Hashes\Sets\Sorted sets等。

    这些复杂数据类型的操作提供了原子操作，不用考虑锁。

2. 内存中运行；可以持久化。

3. 相关网站：

http://redis.io/

http://www.slideshare.net/hitkidnil/memcached-vs-redis

http://www.itlearner.com/article/4890

http://timyang.net/data/redis-misunderstanding/

http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur-in-comparison-to-redis

二、缺点

    官方不支持windows版，有非官方的。这个不是太大问题。

三、性能

1. 内存数据库，性能非常高。

2. 与memcache的性能比较，redis作者给的回答，小数据的存储redis占优，大于100k的memcache占优，但总的来说，一般项目使用时都还不够格考虑这里的瓶颈。

四、使用者及口碑

    暴雪、stackoverflow、github、flickr等等在使用redis。业内口碑非常好。

    http://redis.io/topics/whos-using-redis

五、结合我们项目使用

    由于历史原因，数据库我们先后使用了兄弟公司的k-v数据库，和之后的mysql。

    换数据库，是由于之前的k-v数据库只支持key-value对的存储，value里以json串来存储。这样的存储方式不支持单个字段的更新以及高效的频繁排序等功能算法需求。而游戏编程很需要这些，所以花大气力弥补以前决策的失误，DB换成了mysql。

    项目架构也在调整，php通过handlersocket与mysql进行交互，之前的java只做简单的同步，没有db操作。现在为了性能考虑，在慢慢改成玩家频繁交互的功能和部分别的新功能写在java。这样java就必须与db交互。

    之前为了快速迭代，java与mysql的交互，是java通过http来post存储请求到php，php接到request就立即存储。php这边有老php写的逻辑更新了db字段时，再post一个request到java（java做了个http server），java更新自己的内存。

    这样就有两个问题。

1. 所有与db的操作，cache的地方在handlersocket；（据说有并发写入性能问题——待进一步考证）

2. php与java都要更新db数据时，两个独立的http通道，很诡异，很低效。

    现在有了redis，pub/sub很方便做cache系统。

    一方面php与java相互通知数据更新时，通过redis即可。目前我们先应用急需的这块。当前项目php里使用memcache做交互临时存储以及部分用于加锁的逻辑可以考虑用redis慢慢取代。

    另一方面，以后可以很方便的用redis做我们应用程序与mysql的cache。


ps：2012年12月20日我在CU的博客

一、背景介绍

    由于历史原因，使用了兄弟公司的框架，导致之前的通信序列化协议强制用的JSON。我们项目为一个web项目，前端as，后端php+java，一开始只有as与php短连接，后来为了一些逻辑的实时消息，加了java来另作的长连接。

    as与php都是弱类型的语言，用JSON来序列化，网络通信逻辑可以写的很随意，这导致我们现在查问题非常棘手。另外JSON也浪费了些流量。现在项目在扩展手机前端，对流量的要求更苛刻。为了新老问题的选择，我们就要换掉JSON。

二、序列化协议选择的考虑

    手机前端使用C++写的逻辑，我们协议的要求为跨语言、跨平台、体积小、序列化和反序列化快。

    可供选择的协议有protobuf/thrift/messagepack等。

1. thrift的学习成本貌似比protobuf高些，另外先看的protobuf，感觉两种协议差不多，就懒的继续研究thrift了。

2. protobuf和messagepack的取舍：

    两种皆是开源项目。

（1）protobuf是google主持的，已经被google自己和业内大规模使用了，证明是可靠的；而messagepack貌似出来的比较晚，还没被大规模使用。

（2）语言支持，protobuf官方原生支持C++、Java、python，其他均为第三方扩展；messagepack官方支持C++、Java、php，不支持as，但支持js。

（3）protobuf有个编译器可以自动生成各语言对应版本的协议类；messagepack在强类型如java和C++里就需要自己写各个语言版本的了。

（4）体积方面，messagepack的体积应该比protobuf稍大。

（5）速度方面，messagepack官方说速度是protobuf的4倍，但是看他的测试只是一种语言的序列化测试。

（6）其他，messagepack也支持key-value方式的序列化，号称体积小的JSON。这虽很容易移植以前的协议，为了快速出demo，我也都准备用messagepack先期试改了，但是猛然发现每个语言还是得写各自的，而且现在涉及到两种不同前端，一段的修改还需及时通知另一前端做相应修改。这种太难控制了，没有protobuf的proto文件那种的一致性保证。

三、最终选择

    综合以上的比较，最后选择了protobuf来作为我们项目新的网络通信序列化协议。

ps：2012年9月21日我在CU上的博文