大并发处理

鄙人基本是做PHP 的，现在感觉嘛，有点力不从心，早知道早几年就把现状改变下，毕竟PHP 除了前端展示意外就没多少内容了。要说做的精华点的话，也只能是在架构上有所拓展，但是基本的框架已经由yii 提供了，那就只能是稍微理解下它，学习学习，和实际使用了。这样的进度我是不满意的。

yii 的风格自成一套，感觉后台curd 很舒服，效率挺高，调试也方便，结构清晰，模板也好理解。

就是框架学习总要点成本，后台curd 加个功能还得整半天，一顿好找。

另外就是activerecord 始终效率有点受影响。

说起来，自己用YII 开发以来，也出现过两次问题，一个是数据库插入的时候没有做索引，一个是超级复杂的sql 操作，在并发极高的action 里使用了，两件事情都是很悲剧的，但是现在想来，其实是满简单的，应该说这一年半的系统架构有一定的提高，但是高度稍微上来点后，就会发现越来越不足。

没有足够的项目经验，是最明显的问题。

高并发，现在我们的服务基本转到JAVA 去了，那处理高并发的问题，又有所变迁，反而是最近处理前段的事务比较多。

回到高并发，现在自己在跟进JAVA 文件服务器的问题，也不知道什么幺蛾子的问题，老师会cpu 占用居高不下，怎么处理呢。

需要做缓存的地方基本做了，用了redis，开了3 个进程在跑，两部机子加起来也6 个进程了，但是隔一段时间就要出点报警，很是烦人。

感觉也不是netty 的问题，是业务逻辑的问题，里面跑了两个特殊处理逻辑，一个是图片的 MAGIC ….，一个是APK 文件的签名服务，APK 文件实时处理是嫌疑最大的，毕竟这块处理的文件超大，虽然开了很多线程在跑。

中间件已经是jdk 在管理了，也没别的数据库处理，那如果不是APK 的文件处理问题，那就有可能是redis 的线程机制有问题了