《支付平台架构设计评审核心要点与最佳实践》学习总结
技术出身的产品老大,在微信群里分享了一篇公众号里的文章《支付平台架构设计评审核心要点与最佳实践》。当时上班路上大致扫了一下,后来,我的头儿又转给我,让我好好看看。
昨天和今天得空好好看了一下,应该说是认真学习,收获颇深。
agenda:
-学习总结
-作者原来是个大牛
-《可伸缩服务架构:框架与中间件》
-未来要了解Fastpay项目
文章地址:https://mp.weixin.qq.com/s/y8v9Hd4VD-Ymh8gToU27eQ 当然,网上已经转疯了。
-学习总结
终于弄清楚了乐观锁是何物。 将数据记录的版本号或时间戳用在数据的update操作上,保证数据的强一致性。
渠道通知我们支付结果或代付结果时,我们就使用了这个乐观锁。
冠林在更改账户的可用余额时,也用到了乐观锁。如果更新不成功,会死循环一直重试,直至更新成功。
代付发起的task,也用到了待发送记录的状态值,来保证代付不被重复发起。
悲观锁
sql锁表。我在16年底coding时使用了这种方式,现在更加深了对“悲观锁”的认识。《数据库“锁”事一例:并发情景下重复主键问题方案讨论》
设置db连接超时时间
0416凌晨0:19,因为支付表的很多“Lock wait timeout exceeded;”异常,导致“[DUBBO] Thread pool is EXHAUSTED! ”,线程池满了,故障持续到3点。因为应用线程池满了,导致所有的支付交易和代付交易都不行了。支付表和代付表是2个表,如果设置了db超时时间,那么,影响的只有支付,至少代付可以不受影响的。血淋漓的教训!
同样,读缓存也要设置超时时间。否则也会引起雪崩。
缓存使用
作者给了16个最佳实践。太有用了。
- 将使用缓存的业务进行分离,核心业务和非核心业务使用不同的缓存实例;
- 如果是共享缓存,key的命名要注意(各个应用设定唯一的前缀),避免缓存被覆盖(数据错乱)。如果多个应用共用一个redis,可以考虑用不同的database(redis默认有16个字典数据库),不过并不建议这样做;
- 缓存一般是用来加速数据库的读操作的,一般先访问缓存,后访问数据库,所以缓存的超时时间的设置是很重要的。曾有一家互联网公司遇到过由于运维操作失误导致缓存超时设置得较长,从而拖垮服务的线程池,最终导致服务雪崩的情况。
- 低频访问的数据不要放在缓存中
- 缓存的数据不易过大,尤其是 Redis,因为 我们都知道,redis的一个典型特征就是:核心工作线程是单线程。 单个缓存 key 的数据过大时,会阻塞其他请求的处理。(即大key问题。所谓的大key指的是某个key的value比较大,所以本质上是大value)。
- 在通常情况下,读的顺序是先缓存,后数据库;写的顺序是先数据库,后缓存。
- 在使用缓存时,一定要有降级处理。(缓存有问题或失效,读db)
- 当使用本地缓存(如 Ehcache/hutool-cache)时,一定要严格控制缓存对象的个数及生命周期。由于 JVM 的特性,过多的缓存对象会极大影响 JVM 的性能,甚至导致内存溢出等问题出现。
新代码要兼容老数据
重构代码逻辑时,切记! 新的逻辑要兼容线上目前在跑的交易或逻辑
事务
事务里的操作要尽可能少,提高事务执行时间(减少锁的时长)。 这个意识我是有的,共鸣。 另外,作者提到,使用最终一致性来保证数据的一致性原则。
-作者原来是个大牛
文章里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
集成了聚合支付和资金清结算于一体的统一支付系统。我做的是支付项目,业务和技术都有待提高,所以,久旱逢甘霖,这个必须要了解一下。
当看到一些不好的代码时,会发现我还算优秀;当看到优秀的代码时,也才意识到持续学习的重要!--buguge
本文来自博客园,转载请注明原文链接:https://www.cnblogs.com/buguge/p/8992690.html
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】凌霞软件回馈社区,博客园 & 1Panel & Halo 联合会员上线
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】博客园社区专享云产品让利特惠,阿里云新客6.5折上折
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· 一个费力不讨好的项目,让我损失了近一半的绩效!
· .NET Core 托管堆内存泄露/CPU异常的常见思路
· PostgreSQL 和 SQL Server 在统计信息维护中的关键差异
· DeepSeek “源神”启动!「GitHub 热点速览」
· 微软正式发布.NET 10 Preview 1:开启下一代开发框架新篇章
· C# 集成 DeepSeek 模型实现 AI 私有化(本地部署与 API 调用教程)
· DeepSeek R1 简明指南:架构、训练、本地部署及硬件要求
· 2 本地部署DeepSeek模型构建本地知识库+联网搜索详细步骤