本文为分布式系列文章的集锦汇总,长期保持置顶及更新,读者可以在本文中更好的学习到某个具体的系列。

注: 转载本博客文章请注明出处,原创不易,洗文可耻。

我说分布式事务系列

文章链接
我说分布式事务之TCC
我说分布式事务之最大努力通知型事务
我说分布式事务之可靠消息最终一致性事务1-原理及实现
我说分布式事务之消息一致性事务2-rocketmq的实现
【汇总】我说分布式事务系列
分布式事务之聊聊TCC
分布式事务最终一致性常用方案
TCC-Transaction源码解析之事务执行
TCC-Transaction源码解析之事务补偿
自己写分布式事务框架之原理篇[详解本地消息表]

跟我学RocketMQ

文章链接
[1-1]安装RocketMQ
[1-2]安装RocketMQ-Console管理平台
[1-3]发送普通消息及封装DefaultMQProducer支持spring
[1-4]消费消息及封装DefaultMQPushConsumer支持spring
[1-5]发送事务消息实现分布式事务及封装TransactionMQProducer支持spring
[2-0]跟我学RocketMQ之消息重试
[2-1]跟我学RocketMQ之消息幂等
[2-2]跟我学RocketMQ之消息轨迹实战与源码分析
[2-3]跟我学RocketMQ之消息发送源码解析
[2-4]跟我学RocketMQ之批量消息发送源码解析
[2-5]跟我学RocketMQ之消息消费源码解析-p1
[2-6]跟我学RocketMQ之消息消费源码解析-p2
[2-7]跟我学RocketMQ之订阅关系一致性源码讨论
[2-8]跟我学RocketMQ之消息拉取源码解析
[2-9]跟我学RocketMQ之开源客户端混合云实践与案例解析
[2-10]跟我学RocketMQ之事务消息发送源码解析
[2-10]跟我学RocketMQ之事务消息存储源码解析
[2-11]跟我学RocektMQ之事务消息提交及回查源码解析
[2-12]跟我学RocketMQ之定时消息源码解析
[2-13]跟我学RocektMQ之理解长轮询机制
[2-14]跟我学RocketMQ之消息持久化原理与Mmap
[2-15]跟我学RocketMQ之拉模式消费的两种方式
[2-16]跟我学RocketMQ之聊聊死信队列

分库分表

文章链接
我说分布式之分库分表
跟我学shardingjdbc之shardingjdbc入门
跟我学shardingjdbc之使用jasypt加密数据库连接密码
跟我学shardingjdbc之分布式主键及其自定义
跟我学shardingjdbc之自定义分库分表策略-复合分片算法自定义实现

Read More

本文将主要记录在日常开发中遇到的各种问题。以技术类别进行章节划分,作为个人的编码备忘录随时进行查阅,并长期进行置顶。

问题排查

CPU异常飙高排查思路

cpu占用高如何排查

  • 查看占用cpu高的进程: 通过 top 命令找到 CPU 消耗最高的进程,并记住进程 ID {pid}。

    top -M -n 2 -d 3 >{pid}/top.txt 查看top

  • 再次通过 top -Hp {pid} 找到 CPU 消耗最高的线程 ID,并记住线程 ID(十进制).
  • 通过 JDK 提供的 jstack 工具 dump 线程堆栈信息到指定文件中。

    jstack {pid} >{pid}/jstack_1.txt 一次堆栈快照 备用

    jstack {pid} >{pid}/jstack_2.txt 两次堆栈快照 备用

  • 由于刚刚的线程 ID 是十进制的,而堆栈信息中的线程 ID 是16进制的,因此我们需要将10进制的转换成16进制的,并用这个线程 ID 在堆栈中查找。

    使用 printf “%x\n” [十进制数字] ,可以将10进制转换成16进制。

  • 通过刚刚转换的16进制数字从堆栈信息里找到对应的线程堆栈。就可以从该堆栈中看出端倪。

  • 通过top查看当前进程cpu占用情况,找到cpu使用最高的进程PID
  • 查看子进程情况

    top -p 4606 -H

  • 将 子进程id 转换成16进制

    printf “%x \n” 4648 结果为1228

  • 使用jstack查询具体出现问题的代码位置

    jstack 4606|grep 1228 -C 30

  • 根据打印结果定位到具体代码位置

JavaCore相关

该模块主要记录JavaCore相关的技术点

bigdecimal四舍五入

BigDecimal.ROUND_HALF_UP: 遇到.5的情况时往上近似,例: 1.5 ->;2
BigDecimal.ROUND_HALF_DOWN : 遇到.5的情况时往下近似,例: 1.5 ->;1

bigDecimal转换为百分比,保留若干小数

DecimalFormat decimalFormat = new DecimalFormat("0.00%");
BigDecimal decimal = new BigDecimal(count.intValue()).divide(new BigDecimal(allCount), 5, ROUND_HALF_UP);
String formatted = decimalFormat.format(sdPercent);

bigDecimal精确度

BigDecimal.setScale(5,  BigDecimal.ROUND_HALF_UP)  -->保留五位小数,最后一位遇到.5的情况时往上近似

Read More

复杂软件开发之道系列进行到现在,主要讲的还是理论和思考,但是如何针对DDD编写代码这一问题想必是大家一直关心的问题。

本文我们就小试牛刀,展示一下通过DDD方式编写代码。

1.只有新项⽬才能考虑⽤DDD吗?

当然不是,DDD这套⽅法论不仅适合从零开始的新项⽬的建模,⽽且适 合复杂业务系统的重构。 当然如果能在新模型的建⽴的过程中就使⽤DDD作为指导,是最好不过的事情,原因在于你会省略对原 有业务系统代码逻辑的梳理和适配过程,众所周知,这不是⼀件容易的事情。

Read More

DDD领域驱动设计今年真的是大火了,这是好事,表明我们的软件开发领域是一直在向前发展的。

但是很多的文章或者培训,都是在说DDD如何如何优秀,简单的举一些例子就行了,有些甚至是完全错误的。

因此笔者决定将自己的实践心得以及与他人讨论的关于DDD的问题整理为一篇文章,通过问题驱动的方式,将领域驱动设计中的一些注意点进行总结,希望能够对读者有所帮助。

主要的问题如下:

  • 到底什么才是统⼀语⾔,它有那么重要么?
  • 领域驱动设计仅仅需要开发者参与吗?
  • 领域驱动设计的那些个概念到底是在说什么?实体和值对象有啥区别?
  • DDD四层架构的好处有哪些?
  • 限界上下文如何划分比较好呢?有没有工具推荐?
  • 聚合粒度如何控制呢?一个聚合根就够了,为什么还要细分各种子域?
  • ACL(防腐层)应该怎么用?它的作用和优势有哪些?它在DDD分层中处于哪个位置?

Read More

在笔者的公众号上发布了关于 对账 业务分析的一篇文章,, 该文也是笔者新书中的一节内容。

本文作为补充,我们从实战角度,从代码角度呈现一个对账框架的实现。

注意:本文中提供的对账框架为广义上的对账,也就是说不局限于支付、交易领域的对账场景,凡是需要通过数据比对进行数据校准、比对、核准的场景,均能够采用本文提供的思路进行实现。

Read More

事情的经过是这样的,群友四哥发来一个问题,问大家有什么看法,我看了下,刚好之前接触过类似的业务场景,因此斗胆就问题谈谈自己的看法,抛砖引玉。

问题如下:

A系统联机同步调用B系统(A和B不是同一公司系统,不能用分布式事务),

如何保证系统间数据准实时一致性(聊聊设计思路即可)?

提醒:需要考虑调用超时、并发、幂等、反交易先到等。

各种异常场景怎么处理要考虑更完善些,如事务隔离、并发、反交易先到调用方和服务方约定(前端客户不可能一直等着)

Read More

本次我们不分享技术,我们来聊聊软素质,具体点说,我们来聊聊新人程序员如何快速熟悉业务逻辑并付诸落地。

一个新人程序员,经历了面试的层层磨炼,终于尘埃落定入职心仪的公司。初来乍到,对周围的一切都不熟悉,业务不熟悉,同事也不熟悉。

这其中关系最大的就是对业务和代码的熟悉,如果能够掌握快速熟悉业务逻辑的方法,就能够很快进入到工作角色中,从容不迫的开展新的工作。

那么我们本次分享就从这几个方面展开:

  • 如何通过读代码建立对系统的全局观,cover链路上下游
  • 如何画图来辅助自己熟悉业务流程
  • 应当如何学习掌握领域知识
  • 对于方案设计有哪些技巧和注意点
  • 问题排查的大概思路

PS: 由于大部分的开发者都是面向业务,因此本次讨论对于中间件类的开发不做进一步展开,后面有机会再分享。

Read More

本文是笔者在一次技术直播过程中的文字大纲,基本上是即兴的,口语化严重。
因此对大纲进行整理,用文字方式进行展现。

既然是“漫谈分库分表”,那么我们需要确定我们要谈什么,不谈什么。

  1. 首先,我们不讨论具体的分库分表框架的实现和源码,这不是我们讨论的范围。

  2. 我们讨论的是思路,主要讨论如何分库分表的套路,有什么坑,有什么心得,不针对具体的细节进行展开式讨论。当然我自己的能力有限,只是希望能够抛砖引玉。

  3. 我们要明确,分库分表,并不是一个银弹,它只是我们针对MySQL单机性能不够的情况下,想要节约成本的一种方式。对于boss来说,既想要想要节约成本,又想要支撑业务,提供稳定持久度性能。

Read More

分布式系统开发过程中,我们常常会遇到同时访问多个远程接口,然后在自己的业务逻辑内聚合多个接口的调用结果。这个过程,类比到现实中很像“烧水泡茶”。

在正式讲技术实现之前,我们先以“烧水泡茶”为例,讨论一下并发任务执行在现实中是如何进行的。

烧水泡茶,往往分为如下几步:

  1. 清洗热水壶 (3min)
  2. 烧开水 (8min)
  3. 清洗茶壶 (2min)
  4. 清洗茶杯 (5min)
  5. 准备茶叶 (1min)
  6. 泡茶 (3min)

这个例子,源自著名数学家华罗庚的《统筹方法》一文,先生试图通过这样一个例子,为我们讲解如何进行统筹,组合不同的步骤,能够在最短的时间内喝到茶水。

那么我们就试着分析一下这个案例,如果我们不加优化,直接通过串行方式进行泡茶工序,那么具体的执行路径就如下图所示:

sync-tea.png

Read More

一直推迟到现在,才逼迫自己打开编辑器,敲下题目。

原本都不计划写年终总结了,总觉得没什么可写。这一年,黑天鹅飞过的一年;这一年,节奏飞快的一年;这一年,与口罩度过最长时光的一年;这一年,也是白驹过隙,充满变化的一年。

妻说,写吧,写了这么多年,而且今年这么特别,等多年以后回头再读,想必会有别样的感悟。我无言。

那就写吧,于2020的末尾,我郑重的写下这个题目,关键词,安好、不易、惊喜。

安好,身边的所有人都安好。

年初的疫情席卷而来,经历了在家办公,经历了严密的管控,安好,都好。

2020,好好活着,就是最大的收获。再也没有比生命更让人值得眷恋。

年纪大了,泪点低了,看着新闻里各个地方的感人事迹,人间英雄,大爱无疆,每次都湿了双眼,然后心怀感恩。

活着,活在这片土地,身为国人而活着,骄傲而自信。

母亲从伤病中恢复,浓密的头发再次茂盛,眼角的笑容又一次绽放,一切安好。

不易,在疫情中换了工作,确实不易,当自己从决定换工作到开始行动,再到最终尘埃落定,只用了5天。妻全程陪伴,给予我全方位的关心和鼓励。因为有她所以我能够一直向前。

来到袋鼠团,我发现我爱上了这个团队,学习型的团队,美团就是一所大学,如果你热爱学习,她会提供各种学习的机会,让你提升,让你去挑战自我。虽然白开水有时候确实不太好喝,嗓子难受,不过这不妨碍我们对她的赞美。

来到一个年轻的,充满激情的,有温度的团队,是我的荣幸。2021年,期待和你们继续披荆斩棘,继续纵情,不断向前。

惊喜,我收到了可以说是前半生最珍贵的礼物,也将会是我付出最大努力去关爱的作品。我即将为人父。

惊喜,又有些紧张,伴随着好奇,我陪着妻,等待着他/她的来临,呵,孩子,我们的孩子,陪你一起成长。

感谢妻,给我一个家庭,让我学着成为一个父亲。

总结是条理的,也是纷乱的,有很多事情想说,但是又觉得不足以与这些并列。

往年总是会对自己一年来学习的东西总结,看了多少书,技术提升了多少。

现在感觉这些都是应该做的,还是简单说说吧。

年末在leader的建议之下,建立了公众号,从此博客成为了文章的备份,也收获了300多粉丝,不算多,但是对我而言,有粉丝在,就是对我的督促,我会在公众号里把自己的工作经验和想法全数分享,倾听别人的意见,收获彼此共同的成长。

加入了一个有温度的技术群,群名也很有朝气和学习气息 “业精于勤荒于嬉”,群里的小伙伴涵盖了70 80 90 00 后,大家为了同一个目标“交流技术,提升能力”聚集在一起,和他们交流已经成为生活中的一部分,公众号中的文章也有来自他们的灵感和付出。2021,我们一起立下flag,继续努力提升自己。

2021,黑天鹅还在盘旋,但生活仍在继续。

保持学习热情,继续提升自己的软硬实力,再让自己平和一些,成熟一些;立个flag吧,万一实现了呢。公众号会继续更新,分布式开发中那些常见的套路,会在2021年更新结束;DDD实战经验系列,也会继续更新;

保护好身体,多陪陪家人,学着做一个合格的父亲,像我父亲一样。

保持思考,要多想,保持质疑,不从众,坚持对的,有原则。努力做一个有温度的人,努力做一个有想法的人。

一切过往,皆为序章,我们的征途是星辰大海。

2021,你好。

写于2021.12.31下午,北京。



版权声明:

原创不易,洗文可耻。除非注明,本博文章均为原创,转载请以链接形式标明本文地址。

Fork me on GitHub