周六，一直在考虑如何避免交易冲突的问题，本来想写memcache来记录状态（操作时可以加锁，操作完后解锁），还实践了一把，感觉不是很理想。又搜了一会，伟大的Google告诉我Gae还有Transations这样的东西，我认真地读了英文版又找来了中文翻译，反复看了好长时间，认为这个可行。当晚，就写几个脚本模拟Transations，试到了凌晨1点，结果很让我满意。

      周日下午16:00多，开始在撤单上尝试Transations，试了好长时间，终于调试好了。晚上就将这个股票交易流程用Transactions重写了一遍，临睡前简单地测试了一下，发现了几个笔误，再提交测试，测试OK了。于是，凌晨2点多安心睡觉。

      周一上午，也就是今天，查看了一下log，看起来运转良好，我非常满意！！接下来，该是考虑别的问题的时候了。

      目前，用户已经有12000多了，用户像滚雪球一样慢慢地变大了，我甚至还没有增加用户通知接口。

待解决问题：
1、减少服务器负荷
股市交易时间，每秒钟有近13个request请求，看起来服务器快扛不住了，CPU Time越来越解禁系统极限，要想办法解决了。
想到的解决办法有：
（1）将图片放到另外一台服务器上，应该可以减少3%～5%左右的系统时间。
（2）根据时间，减少用户自行发出的处理请求，这在模板里修改就好。
（3）随着用户的增多，加大用户自发轮询处理的间隔时间。
（4）甚至，减少用户可自发轮询处理的页面。
（5）如果用户增加了，考虑掏钱增加额度，不过尽量想办法。

2、用户数据的存储
现在一万多用户，只占2%，而且用户越来越多，这个比例会线性上升（斜率会增大）。不乐观估计，从存储空间来看，最多只能存储30万用户数据了。
想到的解决办法，
(1) 定时清理用户再也用不到的交易记录。——这个不太好，银行都有存根呢。
(2 )分发在多个服务器上存储——怎么做我还没想好。
(3)实在不行，也只能掏钱了，唉。

3、推出权证T+0交易
用户呼声很高
解决办法：
应该没有问题，但在交易的业务流程上修改一下，还有Memcache一下正股的股票价格。不过增加T+0交易，对系统的CPU要求越来越高拉。

走一步看一步了，其他的先放一放，先将注意力集中在紧急重要的几个问题上。