目前的方案是用一个独立进程去渲染图片，然后通过共享内存的方式，把渲染结果提供给游戏客户端。这较好的解决了多个客户端的性能下降问题。 我认为，这也是继续延用 2d engine 做核心的优势。（当然更重要原因是，这个游戏的客户端程序不适合重新制作，否则重制版一旦出现严重问题，对公司影响太大）
Kyoto Tycoon 是一个轻量级的数据库服务器， 支持自动过期的实现，这个在各种需要处理缓存数据的程序中很有用。Kyoto Tycoon 也是一个叫Kyoto cabinet的DBM的网络接口。虽然这个DBM拥有很高的性能和并发能力，但是你在处理多进程共享一个数据库，或是需要远程访问一个数据库时感到头痛。而Kyoto Tycoon就是提供来处理Kyoto cabinet的并发处理和远程连接的。Kyoto tycoon由管理各种各样数据库的服务器进程和访问服务器的客户端程序库组成。
采用基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法，推荐引擎常用Content-Based 推荐算法及协同过滤算法（Item-Based 、User-based）。但从实际应用来看，对于大部分中小型企业来说，要在电子商务系统完整采用以上算法还有很大的难度。
我们前面描述的OAuth，被称为三条腿的OAuth（3-Legged OAuth），这也是OAuth的标准版本。这里所谓的“三条腿”，指的是授权过程中涉及前面提到的三种角色，也就是：消费方，服务提供者，用户。不过有些情况下，不需要用户的参与，此时就产生了一个变体，被称作两条腿的OAuth（2-Legged OAuth），一般来说，访问私有数据的应用需要三条腿的OAuth，访问公共数据的应用需要两条腿的OAuth。
两条腿的OAuth和三条腿的OAuth相比，因为没有用户的参与，所以在流程中就不会涉及用户授权的环节，也就不需要使用Token，而主要是通过Consumer Key和Consumer Secret来完成签名的，此时的Consumer Key和Consumer Secret基本等价于账号和密码的作用。
说memcached是妖孽，并不是因为memcached应用了之后性能狂升――这本是意料之中的事情，不这样反而才奇怪――而是因为我基本上没花多少时间就实现了这么妖孽的效果，至少我花的时间并不比写这篇blog的时间多。那么方便的使用方法和那么显著的性能提升状况真是让人咋舌。
-
[16] 浏览器的工作原理：新式网络浏览器幕后揭秘 -
[15] Go Reflect 性能
-
[14] 界面设计速成
-
[13] Spark性能优化——和shuffle搏斗
-
[13] iOS可视化编程 Tips 之“无需代码设置
-
[13] iOS下自己动手造无限循环图片轮播
-
[12] iOS并发编程（Concurrency Pr
-
[12] 最萌域名.cat背后的故事：加泰与西班牙政府
-
[11] 基于HTTP缓存轻松实现客户端应用的离线支持
-
[11] 内网穿透神器frp
