<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[luxianping的专栏]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/luxianping</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; luxianping]]></copyright><item><title><![CDATA[领域驱动设计理解及实践探讨]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/149115768</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/149115768</guid><author>luxianping</author><pubDate>Fri, 04 Jul 2025 13:31:38 +0800</pubDate><description><![CDATA[DDD 是一种思维方式，不是概念的教条。]]></description><category></category></item><item><title><![CDATA[别让依赖拖垮架构！你真的懂依赖倒置吗？]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/148639105</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/148639105</guid><author>luxianping</author><pubDate>Fri, 13 Jun 2025 21:30:56 +0800</pubDate><description><![CDATA[外部接口的超时重试、外部接口的故障降级，这些和业务不相关，在业务层不应该关心这些问题。然而，在传统开发模式的实际应用中，尽管多数项目在代码层面进行了诸如 controller、service、dao、third-api 等包的划分，但这些看似规范的分层，实则常常沦为徒有其表的 “空壳”，内部充斥着混乱无序的代码，如同难以梳理的 “代码屎山”。例如，在选择短信发送通道时，我们会考量各种限制：稳定性、发送速度、价格、合规性等问题，但若出现更合适的选择，我们能够轻松更换，而不是被某一供应商绑定，陷入依附的困境。]]></description><category></category></item><item><title><![CDATA[Workflow轻量级工作流引擎实现]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/147352485</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/147352485</guid><author>luxianping</author><pubDate>Sat, 19 Apr 2025 16:39:13 +0800</pubDate><description><![CDATA[在启动流程或处理任务时，可以传入 busId（业务唯一标识），流程节点处理器内部即可获取该 busId，从而实现与具体业务数据的关联。这边有一个特殊的地方就是，条件解析器必须得继承 RedissionSafeConditionParser，因为会签会存在多个人并行的情况，需要依赖 redis 的分布式锁来解决问题。用于判断当前任务是否可以流转到下一个流程任务，类似工作流里面的多人会签，当多个人都完成的时候才可以流程到下一个流程任务节点。一通写下来，总感觉哪里不对，“为什么加新的任务节点，要改已有的代码呢？]]></description><category></category></item><item><title><![CDATA[轻量级TCC框架的实现]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/146139374</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/146139374</guid><author>luxianping</author><pubDate>Sun, 09 Mar 2025 22:18:05 +0800</pubDate><description><![CDATA[现有seata、tcc-transaction等tcc框架实现都较为重量级，今天主要带来一种轻量级的实现，大概只用了1200行代码实现。不依赖具体框架grpc、http、dubbo等，只需要业务系统按照标准化实习Try、Commit、Cancel实现接口即可。已解决悬挂、幂等、空回滚、事务嵌套问题，业务层面无需关注这部分处理。]]></description><category></category></item><item><title><![CDATA[如何通过事件溯源实现百万TPS全内存撮合交易引擎]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/143323082</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/143323082</guid><author>luxianping</author><pubDate>Tue, 29 Oct 2024 11:51:05 +0800</pubDate><description><![CDATA[当对股票聚合根在多台机器出现的时候，就会有产生Event版本号冲突的问题，所以在Event入库的时候，只要出现唯一索引冲突，就代表了出现了更新冲突。本人并没有从事过股票交易相关系统的开发经验，只是单纯个人喜好，根据网络上相关的一些撮合业务的描述，按照自己的理解实现的一套基于事件溯源的全内存撮合引擎。每个事件都代表一个状态变化，应用程序的状态是通过这些事件的序列重建的。撮合产生的交易Event信息，是采用批量组提交的模式进行入库到数据库磁盘中的，即使断电了也可以通过磁盘中的Event恢复的最新的状态。]]></description><category></category></item><item><title><![CDATA[电商购物车设计（附案例学习）]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/130359412</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/130359412</guid><author>luxianping</author><pubDate>Tue, 25 Apr 2023 10:34:56 +0800</pubDate><description><![CDATA[也就是说它的设计是分层的，除了基础（default）的设计之外，我们还需要叠加上一层业务的特性，它最终的呈现也与业务有着很强的关系。用户会选择多件商品放到购物车里，也会对购物车内的商品买多或减少几件，甚至后悔删除某些商品。总结：每个产品在细节处理上都有细微的不同，但商品失效管理功能的设计的核心在于提示用户购物车内的某些商品无法购买了，不因为商品突然不见或无法购买而造成困惑。例如京东的凑单设计，结合运费减免，激励用户选择更多的商品以达到免运费的总价要求，购物车就这样在无形中销售了更多的商品。]]></description><category></category></item><item><title><![CDATA[动态规则表达式解析]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/128621593</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/128621593</guid><author>luxianping</author><pubDate>Mon, 09 Jan 2023 21:40:40 +0800</pubDate><description><![CDATA[动态规则表达式解析。]]></description><category></category></item><item><title><![CDATA[思考：如何保证服务稳定性？]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/128564418</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/128564418</guid><author>luxianping</author><pubDate>Thu, 05 Jan 2023 15:35:36 +0800</pubDate><description><![CDATA[混沌工程是近几年比较火的名词，通过不断给系统找麻烦来验证并完善系统能力，阿里在这块花了很大的精力建设红蓝军对抗攻防，进行定期和不定期的演练，最后以打分的形式来给各个部门系统做排名，除了系统层面的故障演练外还有资金演练，篡改线上sql语句制造资损来测试业务监控纠错的能力，通过制造小错来避免大错。：起源于15年某施工队将光纤挖断带来的支付宝故障，由此出来的三地五中心和单元化架构，异地多活本身的成本比较高，然后又存在数据同步的延时问题和切流带来的脏数据问题，对于业务和技术都有比较高的要求。]]></description><category></category></item><item><title><![CDATA[Java实现4种微信抢红包算法(小结)]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/125471551</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/125471551</guid><author>luxianping</author><pubDate>Sun, 26 Jun 2022 16:50:04 +0800</pubDate><description><![CDATA[....]]></description><category></category></item><item><title><![CDATA[如何通过基于事件溯源架构高效解决12306的库存问题]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/122857386</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/122857386</guid><author>luxianping</author><pubDate>Thu, 10 Feb 2022 11:42:00 +0800</pubDate><description><![CDATA[12306主要性能问题还是出在出票和余票查询。当前通过CQRS架构结合聚合根在内存、事件回溯的手段来解决以上两个问题。 实现了买票、退票、站点最多可卖座位数限制、 站点间预留票(最低保留座位数，最多可卖座位数)、取消预留票功能。主要用到两个数据结构为跳表、位图。

假设车次k41有途径4个站点分别为1，2，3，4，总共8个座位。1.初始化车次站点票信息

10002 表示表示站点1到站点2, 0000 0000 表示有8个座位，下标从0-7.
20003 表示表示站点2到站点3, 0000 0000 表..]]></description><category></category></item><item><title><![CDATA[Java中“附近的人”实现方案讨论及代码实现]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/122806065</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/122806065</guid><author>luxianping</author><pubDate>Mon, 07 Feb 2022 11:17:22 +0800</pubDate><description><![CDATA[1|0 前言

在我们平时使用的许多app中有附近的人这一功能，像微信、qq附近的人，哈罗、街兔附近的车辆。这些功能就在我们日常生活中出现。


像类似于附近的人这一类业务，在Java中是如何实现的呢？


本文就简单介绍下目前的几种解决方案，并提供简单的示例代码

注: 本文仅涉及附近的人这一业务场景的解决方案讨论，并未涉及到相关的技术细节和方案优化，各位看官可以放心阅读。

2|0基本套路和方案



目前业内的解决方案大都依据geoHash展开，考虑到不同的数据量以及不同的业务场景，本文主要讨论以下3]]></description><category></category></item><item><title><![CDATA[我做系统架构的一些原则]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/122080370</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/122080370</guid><author>luxianping</author><pubDate>Wed, 22 Dec 2021 10:46:28 +0800</pubDate><description><![CDATA[工作 20 多年了，这 20 来年看到了很多公司系统架构，也看到了很多问题，在跟这些公司进行交流和讨论的时候，包括进行实施和方案比较的时候，都有很多各种方案的比较和妥协，因为相关的经历越来越多，所以，逐渐形成了自己的逻辑和方法论。今天，想写下这篇文章，把我的这些个人的经验和想法总结下来，希望能够让更多的人可以参考和借鉴，并能够做出更好的架构来。另外，我的这些思维方式和原则都针对于现有市面上众多不合理的架构和方案，所以，也算是一种“纠正”……（注意，这篇文章所说的这些架构上的原则，一般适用于相对比较复杂的业务]]></description><category></category></item><item><title><![CDATA[你应该知道的计算机延迟数字]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/117997677</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/117997677</guid><author>luxianping</author><pubDate>Thu, 17 Jun 2021 17:08:29 +0800</pubDate><description><![CDATA[了解常见的计算机延迟，有助于架构设计和问题排查。比如互斥锁延迟，硬盘存取延迟，网络延迟等等。通过了解不同设备或环境的延迟的数量级，就很容易理解redis为什么比mysql快很多，异地多活架构有多难。

本文从微观的CPU时钟延迟开始，到宏观的异地双机房网络延迟，描述各种延迟的数量级。

延迟的定义

如下是维基百科对延迟的定义：


Latencyfrom a general point of view is a time delay between the cause and the effect of.]]></description><category></category></item><item><title><![CDATA[Kotlin协程原理解析]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114969108</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114969108</guid><author>luxianping</author><pubDate>Thu, 18 Mar 2021 11:08:21 +0800</pubDate><description><![CDATA[Kotlin协程实际上是所谓的stackless协程，即没有在线程之上实现类似线程栈的结构，可以认为是一种kotlin语言层面支持的 线程调度框架，使用这个框架，我们可以省去手动书写callback，使代码看上去是同步的

使用了协程以后，原本需要回调实现的非阻塞功能可以用阻塞的方式去写，比如：




launch {
    // 异步读时挂起
    val bytesRead = inChannel.aRead(buf)
    // 读完成后才执行这一行
    ...
    ...
    .]]></description><category></category></item><item><title><![CDATA[没有关系数据库、事务如何做一个交易系统]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114610893</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114610893</guid><author>luxianping</author><pubDate>Wed, 10 Mar 2021 00:47:32 +0800</pubDate><description><![CDATA[之前一次心签到有提到如果没有关系数据库、没有事务我们要如何做一个在线交易的系统。这个对于以往重度依赖数据库、事务机制开发的同学会一头雾水，这要如何去做？我相信也有一部分人会觉得很疑惑。这和我以往开发的方式完全不一样？很多时候在一个分布式的系统里面我们是很难做到ACID的机制的，所以又演化出BASE理论，BASE理论是允许或容忍系统出现暂时性的问题。那如何应用这个理论来解决我上面说的这个问题。那提出一个新的观念：补偿事务。我们可以通过现实生活中的例子来看看是怎么做的。比我我现在要出差，首先要请假、买机票这两.]]></description><category></category></item><item><title><![CDATA[JAVA 线上故障排查全套路]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114461076</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114461076</guid><author>luxianping</author><pubDate>Sat, 06 Mar 2021 22:39:50 +0800</pubDate><description><![CDATA[线上故障主要会包括 CPU、磁盘、内存以及网络问题，而大多数故障可能会包含不止一个层面的问题，所以进行排查时候尽量四个方面依次排查一遍。同时例如 jstack、jmap 等工具也是不囿于一个方面的问题的，基本上出问题就是 df、free、top 三连，然后依次 jstack、jmap 伺候，具体问题具体分析即可。

CPU

一般来讲我们首先会排查 CPU 方面的问题。CPU 异常往往还是比较好定位的。原因包括业务逻辑问题(死循环)、频繁 gc 以及上下文切换过多。而最常见的往往是业务逻辑(或者框架逻辑)导]]></description><category></category></item><item><title><![CDATA[同步调用与异步调用分析]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114416290</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114416290</guid><author>luxianping</author><pubDate>Fri, 05 Mar 2021 21:58:17 +0800</pubDate><description><![CDATA[服务与服务间的调用方式分为两种同步调用、异步调用。同步调用可以理解为A打电话给B，需要实时响应，异步调用类似A给B发送邮件，B不需要马上回复。这两种调用方式应该说都有的优缺点。但是在面对一个高并发吞吐量的系统，异步方式比同步方式可以大大增加系统的吞吐量。A,B,C,E可以同时给F发送邮件，F可以不在线，不用立即回复。对于服务化后服务与服务之间的调用也类似这样一个原理。同步调用虽然只是耦合外部接口，实时性上会高于异步调用，但是会带来很多的问题。
1.调用方的吞吐量受限于被调用方的吞吐量，一旦某个服务响应特..]]></description><category></category></item><item><title><![CDATA[盘点一下我用kafka两年以来踩过的一些非比寻常的坑]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114395670</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114395670</guid><author>luxianping</author><pubDate>Fri, 05 Mar 2021 14:33:15 +0800</pubDate><description><![CDATA[前言

我的上家公司是做餐饮系统的，每天中午和晚上用餐高峰期，系统的并发量不容小觑。为了保险起见，公司规定各部门都要在吃饭的时间轮流值班，防止出现线上问题时能够及时处理。

我当时在后厨显示系统团队，该系统属于订单的下游业务。用户点完菜下单后，订单系统会通过发kafka消息给我们系统，系统读取消息后，做业务逻辑处理，持久化订单和菜品数据，然后展示到划菜客户端。这样厨师就知道哪个订单要做哪些菜，有些菜做好了，就可以通过该系统出菜。系统自动通知服务员上菜，如果服务员上完菜，修改菜品上菜状态，用户就知道哪些菜..]]></description><category></category></item><item><title><![CDATA[256变4096: 分库分表扩容如何实现平滑数据迁移?]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114395420</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114395420</guid><author>luxianping</author><pubDate>Fri, 05 Mar 2021 14:29:32 +0800</pubDate><description><![CDATA[一 背景

2020年，笔者负责的一个高德打车弹外订单系统进行了一次扩分库分表和数据库迁移。该订单系统整体部署在阿里云上，服务使用阿里云ECS部署，数据库采用阿里云RDS，配置中心基于阿里云ACM自研，数据同步基于阿里云DTS自研以及自研分库分表组件、分布式ID组件等等。

此次进行扩分库分表的背景是，原4实例4库、每个库64张表一共256张表，部分单表已超千万量级，按当前每日单量量级，一年内单表会达到上亿条记录，单表数据量过大会带来数据库性能问题。

注：[弹内弹外]弹是指弹性计算，弹内与弹外其实是指..]]></description><category></category></item><item><title><![CDATA[排队（顺序消费）+Group commit]]></title><link>https://blog.youkuaiyun.com/luxianping/article/details/114380126</link><guid>https://blog.youkuaiyun.com/luxianping/article/details/114380126</guid><author>luxianping</author><pubDate>Thu, 04 Mar 2021 22:55:34 +0800</pubDate><description><![CDATA[阿里早期开源过一个mysql的分支alisql，他有一个特性特别吸引人，支持在mysql 引擎层对单条数据的修改进行排队的功能。这个特性能给我带来什么样的好处呢？比如我们现在有一个需求要做微博点赞量的计数器，在不用redis缓存相关技术，基于现有的技术很难做到高性能。而alisql为我们考虑的这个问题，mysql我们都知道如果一条记录存在同一个时间非常多线程去更新的时候性能非常的差。列出一个测试数据：mysql 5.6 版本，8个线程同时更新一条记录的TSP大概是4.3k，当加大512个线程去更新...]]></description><category></category></item></channel></rss>