2012-3用户数据迁移及SNS

1)用户数据迁徙

1.每次处理的数据要有一定的批量，保证内存和CPU占用稳定，不会内存溢出。

2.在一定情况下，用可重复执行和报错机制来代替事务。比如change_log和数据操作不强调事务。

一.如果前后空格无意义，数据库入库时要截断前后空格。

二.同一字段在不同数据库或者同一数据库不同表中存储大小写要一致。不能数据库不区分，就存不一致的。

三.数据库或者保持全角半角一致（同上），或者只存半角。一定不能有的地存全角，有的地存半角。

四.如果业务要求字段唯一，数据库要做唯一限定。

五.不可太相信业务系统，可以开发个非法数据检测程序来定期检查数据库是否有非法数据进入，比如全半角，非法字符，一致性。

一.程序处理数据一定要分批量，保持CPU和内存在每个批量时的效率稳定。

二.在集合中根据属性查找数据，不要使用循环，建立一个Map，然后从Map中直接取会快很多。

三.编程时要考虑部署的复杂程序，部署越简单越好。

四.接手代码研发，两种思路，1.只要程序正确，尽少做出改动。2.在能满足工期的情况下，尽可能的改动代码（当然是往好的方便改），接手这个程序原来是想采用第一个思路，后来在一定程度上使用了第二个思路，有些后悔没有一开始就采用第二个思路。

面向对象在消除重复代码（既代码复用）和代码维护有着非常重要的作用。面向过程的程序在重复代码封装和功能聚合时就是面向对象了，可以理解面向对象就是对面向过程的基础上进行了高内聚和低耦合的封装，而且是根据业务需要来封装的。(当然一开始就整个使用对象来思考更理想，但一个人不太可能会全部完完全全的全部用面向对象来思考，有时退一步这样思考还是很有好处的，面向对象和面向过程本身就分不开)很不幸，本程序大部分是面向过程的，而且存在很多类似代码重复。维护起来还是有些痛苦的。

2)2011-11用户数据迁徙重构

1.容错处理的引入，非功能性需求的考虑

2.无效线程的引用，线程要用到性能瓶颈的地方。

原来一个程序处理一个库，一个库用10个线程写数据。改用一个程序用10个线程处理10个库，每个库一个线程来处理。

3)2012-8 数据迁移重构

1.重复以及相似代码进行梳理,冗长的调用链条和无效类进行清理。

2.线程协作由wait和notify换成blockQueue

?

3.同步原来是取完再通知，新的是取完再新建立线程组来消费，如果用协作，因为没有保留已经取的状态，故可能会取重复，所以在消费latch完再取。

?

4）2012-7 SNS库迁移

?

性能优化要优化瓶颈，原来一个写入，后来改为10个写入。