当一家银行决定每周五10:00、11:00固定的时间点进行相关优惠券秒杀活动时，本身就是业务对科技的最大挑战。类似每年的双11活动，阿里逼迫银行不断的优化系统，提高处理能力。有幸参与秒杀活动的优化，本身就是对技术人员的一种无上荣誉。
秒杀应用具有很强的特点：交易短时间完成（快）、商品不能超卖（准）、秒杀不能影响其它业务（稳）。转换成技术术语就是 高性能、一致性、高可用。为了实现这些，我们需要在设计上遵从一定的原则，缩短交易链路、减少网络传输、减少请求、减少系统依赖，做到多个层次的隔离。
当前端接入成为高速高路，后端系统还是国道省道的时候，动态限流是最好的选择，虽然影响了客户的体验，但总比无法使用好，唯一的解决之道就是不断的进行秒杀链路上的不断优化，做到极致编码，每个流程能减少10毫秒就是胜利。只有在这种高并发的挑战下，你才会觉得架构、设计、编码是多么的重要。下面是一些代码案例，可作为日常开发中的一些警示：
1、日志同步、异步、有效记录，debug没有先判断级别，再进行日志处理，导致交易时间拉长
2、缓存失效原则，本地缓存优于Redis缓存的原则，不是记住就可以，关键要会使用。Redis是秒杀应用的常客，但是日常开发我们是否一定要让Redis和应用形成强依赖我也没有答案，希望明年1月的培训，高人能给我答案。
3、JDK1.6下的高并发parseDouble的锁机制，如果想避免可以使用parseLong* Math.pow（）来提高，类似12.14可以表示为1214*10的负2次方，因为parseLong不会有锁，当然JDK1.8已经进行优化，可是该死的应用用了WAS8，却选择了JDK1.6，会让你有时候很无语。
4、XML不是一个好的应用间接口传递方式，互联网已经抛弃，但是银行历史包袱太重，对于秒杀应用来说，明显不适应，10K的XML报文换成JSON或者RCP也许不到1K，更要命为了通用，底层框架使用了 //方式的XPath去获取节点属性，时间哪个长，CPU哪个高，定制优于通用。
其实XML极致的时候，可以将解析XML的工厂对象也进行缓存，避免每次JDK底层去通过SPI寻找文件定义，这里在高并发下至少可以提高上百左右的TPS（只是说纯XML解析为Dom的过程）。
5、冒泡排序，这种教课书式的排序，一定不是最快的，JDK底层的快速冒泡排序是对它的优化，所以开发人员不要自己去写，能交给JDK的我们就尽量交给他，前提你需要知道有这个。200ms的500个对象的排序，可以瞬间让你到30ms，何乐而不为呢。
秒杀优化永无止境，JMeter、JConsole、Arthas、MAT、NMON、Redis是我们必备的技能，掌握秒杀的基本特点，设计合理的架构，做到极致的编码，把系统做到高性能，高可用是我们努力的方向。2周的优化终归有一些收获，总结一下，且行且珍惜。
