技术出身的产品老大，在微信群里分享了一篇公众号里的文章《支付平台架构设计评审核心要点与最佳实践》。当时上班路上大致扫了一下，后来，我的头儿又转给我，让我好好看看。
昨天和今天得空好好看了一下，应该说是认真学习，收获颇深。
-学习总结
-作者原来是个大牛
-《可伸缩服务架构：框架与中间件》
-未来要了解Fastpay项目
文章地址：https://mp.weixin.qq.com/s/y8v9Hd4VD-Ymh8gToU27eQ 当然，网上已经转疯了。
-学习总结
终于弄清楚了乐观锁是何物。 将数据记录的版本号或时间戳用在数据的update操作上，保证数据的强一致性。
渠道通知我们支付结果或代付结果时，我们就使用了这个乐观锁。
冠林在更改账户的可用余额时，也用到了乐观锁。如果更新不成功，会死循环一直重试，直至更新成功。
代付发起的task，也用到了待发送记录的状态值，来保证代付不被重复发起。
悲观锁
sql锁表。我在16年底coding时使用了这种方式，现在更加深了对“悲观锁”的认识。《数据库“锁”事一例：并发情景下重复主键问题方案讨论》
设置db连接超时时间
4月16日凌晨0:19，因为支付表的很多“Lock wait timeout exceeded;”异常，导致“[DUBBO] Thread pool is EXHAUSTED! ”，线程池满了，故障持续到3点。因为应用线程池满了，导致所有的交易都不行了。支付表和代付表是2个表，如果设置了db超时时间，那么，影响的只有支付，至少代付可以不受影响的。血淋漓的教训！
同样，读缓存也要设置超时时间。否则也会引起雪崩。
缓存使用
作者给了16个最佳实践。太有用了。
- 将使用缓存的业务进行分离，核心业务和非核心业务使用不同的缓存实例；
- 如果是共享缓存，key的命名要注意（各个应用设定唯一的前缀），避免缓存被覆盖（数据错乱）；
- 缓存一般是用来加速数据库的读操作的，一般先访问缓存，后访问数据库，所以缓存的超时时间的设置是很重要的。曾有一家互联网公司遇到过由于运维操作失误导致缓存超时设置得较长，从而拖垮服务的线程池，最终导致服务雪崩的情况。
- 低频访问的数据不要放在缓存中
- 缓存的数据不易过大，尤其是 Redis，因为 Redis 使用的是单线程模型，单个缓存 key 的数据过大时，会阻塞其他请求的处理。
- 在通常情况下，读的顺序是先缓存，后数据库；写的顺序是先数据库，后缓存。
- 在使用缓存时，一定要有降级处理。（缓存有问题或失效，读db）
新代码要兼容老数据
重构代码逻辑时，切记！ 新的逻辑要兼容线上目前在跑的交易或逻辑
事务
事务里的操作要尽可能少，提高事务执行时间（减少锁的时长）。 这个意识我是有的，共鸣。 另外，作者提到，使用最终一致性来保证数据的一致性原则。
-作者原来是个大牛
文章里2次提到了《可伸缩服务架构：框架与中间件》这本书，京东上看了一下，原来这篇文章的作者李艳鹏是主编。瞬间觉得其人NB。
李艳鹏，“云时代架构”技术社区合伙创始人。
云时代架构：http://www.cloudate.net/
《可伸缩服务架构：框架与中间件》的另一主编——贾博岩，简书有专博，看了几篇技术文章，较有难度。https://www.jianshu.com/u/c98c50394601
-《可伸缩服务架构：框架与中间件》
jd上看了介绍和评价，是本很牛的书籍。如果能读完，技术能力定能提高不少。 不过单看目录，有些章节都觉得难。这是本新书，今年3月份出版发行的，80多块钱，小贵（潜意识里就是这么一个人，花在别的方面也许不犹豫，买本能提高自我的书却不舍得投资），可以跟领导申请一下是否可以用部门经费为部门买些书籍。https://item.jd.com/12308233.html
-未来要了解Fastpay项目
开发包：https://gitee.com/robertleepeak/fastpay
集成了聚合支付和资金清结算于一体的统一支付系统。我做的是支付项目，业务和技术都有待提高，所以，久旱逢甘霖，这个必须要了解一下。