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

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

我说分布式事务系列

文章链接
我说分布式事务之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

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

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

  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下午,北京。



版权声明:

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

学习DDD的时候,作为开发更关心它技术层面的东西,尤其体现在DDD的分包方式、编码技巧等方面。

我们不禁发问,用了DDD的分包,就是实践落地了DDD了么?

不卖关子,直接说答案,并不是。

用了DDD的分包,只能说满足了DDD的形,并没有抓住DDD的神。DDD的神是什么,归根到底还是面向对象,领域建模。所谓的各种分包方式本质上还是为了满足DDD面向对象的本质,方便开发者进行代码编写而提供的一种”战术设计”工具.

要深入讨论这个问题,我们需要花一点时间来学习讨论一下DDD中常见的几种分包。

Read More

软件开发领域中,软件复杂度是一个由来已久的话题,从软件的诞生到成熟再到消亡,或多或少总会伴随着软件复杂度的讨论。

我们不禁发问,软件复杂度究竟从何而来?

谈到软件复杂度,有三个话题不得不提及,他们分别是软件规模,软件结构,以及业务的变化。

首先是 软件规模,它涉及到软件本身的代码量,迭代时长以及迭代的次数/数量,以及该软件经手的开发者数量等。这几个要素都会对软件规模造成显著影响,可以回想一下自己接手别人祖传代码时那种忐忑不安、小心翼翼的心态,生怕因为自己的失误导致出现bug甚至背锅的情况;并且代码规模越大,业务逻辑越冗长,这种心态就越发强烈。

Read More

今日的后端开发,我们常常听到大家提到“领域驱动设计”、“DDD”等名词,听起来感觉很高端,自己也忍不住想了解,但是又不知从何下手。

不慌,我们这个系列的意义就在于用浅显易懂又不是深度的叙述手法,为大家全方位的介绍普及DDD领域驱动设计的知识,并最终落地到自己的项目中。

那么,我们直接进入正题,领域驱动设计(接下来为叙述方便,用DDD代指)到底是什么?

Read More

随着业务发展,软件本身也需要不断进行迭代以适应业务变换。

我们可以说,软件存在的价值就是映射真实世界,解决业务问题,从而创造更多价值,为大众提供更加便利的服务。

面对复杂业务场景,我们往往通过不断增加业务分支,对原有的冰山一样的代码逻辑进行小心翼翼的修改,生怕因为自己的修改导致全局出现不可挽回的损失。

这种不断迭代的历史遗留代码,几十年前的《人月神话》已经下过一次定义–“焦油坑”。

我们也常常调侃,自己不是在写代码,而是在Ctrl C / V, 在代码的“shit mountain”山不断进行着业务逻辑的搬运,并时刻祈祷系统别出异常,从而成为背锅的那个人。

这种现实是否能够通过一定的方式/方法/技巧改善甚至说这种类型问题能否改善呢?

Read More

日常开发中,对于遗留系统代码逻辑的改造,通常不会粗暴地采用停机更新方式直接迁移到新业务逻辑,往往需要通过灰度方式逐步迁移到新逻辑,最后再把老业务逻辑下线。

这个过程中就涉及到新老业务逻辑并存的问题,而这个问题是需要研发同学去通过工具、编码、配置等方式实现灰度策略,制定灰度计划,并付诸实施,保障系统能够平稳地从老业务逻辑迁移至新业务逻辑。

通常情况下,如果是http接口灰度,我们可以利用网关的特性,如nginx自身的能力,根据cookie中传递的唯一标识进行百分比分流,通过免开发的方式进行灰度。

但在实际开发中,我们面对的系统不仅仅是网关类系统,大部分情况下,分布式系统开发场景下面对的是RPC类接口或者异步消息逻辑,对于这类型代码逻辑的灰度就需要研发同学通过编码方式,细粒度的进行灰度。

本文中,我们就后者展开代码级别的讨论和分享,向读者介绍笔者在日常开发中,面对接口级别的灰度场景是如何通过编码实现具体的灰度策略的,本文权当抛砖引玉,为读者全景展示​后端研发套路之灰度场景下的瑞士军刀具体是如何使用的。在今后的开发工作中如果你遇到类似场景,可以参考笔者思路,开发适合自己业务的灰度套路。

Read More

Fork me on GitHub