今天有幸参加了另外一个项目的架构会议，会上老大提出了要求，在项目上线前要合理的预估后台的并发访问量，预估程序的内存使用量，这个也是经常提到的一个话题，就是说你的程序整体运行在一个可控的环境下，不能出现大量的内存泄漏，并且有一个应对方案，OOM呢还是？现在正在开发的项目可能着眼于需求，后面也需要提前来预估这些数量，这又不禁让我想起了一本书，书名大概是程序员的概率与统计，讲的也和这方面相关，就是说在面对一些不确定的问题时，我们需要一个确切的解决方案来应对，这需要经验，需要技术，而这也是我要学习的！
同样是这个项目，在实现的过程中，可能需要根据日期来将数据放在不同的表格中，刚好前两天看过MySQL分表的实现，满足需求啊，而且是数据库帮你把这活干了，不用应用层去记录日期到数据文件的映射。人丑还是要都读书哇！索引在创建时，或者在重建时，需要对数据库进行加锁，哇哦，这会影响性能。又是索引重建，是不是很熟悉呢？
进程与线程，在面试时经常问到这个问题，创建的开销，调度的开销，编程的模型，都不一样，会议上说的进程和线程差不多，我不是很认同
为什么要开这个架构的会议呢，因为之前项目采用的NoSQL数据库不能满足应用的需求了，不能支持一些复杂的关系查询。要我说，如果查询数据时有多于一个where的情况，建议使用MySQL这种关系型数据库。像现在的游戏服，NoSQL只是存储了一个UID到PlayerInfo的映射，没有其他逻辑，很适合用NoSQL。又想起之前在学校应付老师的汇报，说用红黑树实现了一个key-value的查询，同时，又想通过增加额外的信息来实现value->key的查询，后面由于实现太复杂放弃了，哈哈！
开完会一个小小的需求难住人了，如果说是应付差事，那改改代码就好，可是得有点责任心啊(此处有掌声)，在满足当前需求的情况下，还得适当的考虑下可扩展性，后面又有新需求了，又改代码，反正我是不想改！
早点休息~
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
