MaoLin Tian's Blog

今年比较遗憾的就是哪儿都没出去玩儿，好在去年的愿望【年终总结系列 2023】新起点，同时追寻更高的起点部分实现了。所以减肥还是很重要的，2025年减肥成功，搬进新家，迎接小宝贝到来！

同事件风暴一样领域建模也是在模型建立阶段，但更进一步的，领域建模不仅要对业务进行直观模拟，更要经过提炼，形成浓缩的知识，使模型中的知识不再停留在业务的表面，而是深入到业务的本质，进而加入技术视角选择最合适的建模方案。可以理解为是对事件风暴的技术性加工，使用UML图的一些标记例如：注释、约束、多重性、自关联、多关联、角色以及一些技巧如：多对多关联拆分、抽象化实体、模块化来进行领域建模。一个比较深的体会是对于多对多关联拆分的考虑，例如业务事件阶段的【门店、合作】以领域名词的形式候选为实体，在领域建模阶段明确其多

事件风暴不仅能帮助我们尽量把需求补充完全，而且还能以协作的方式保证业务人员和技术人员对需求理解一致。实践过程中有点儿像模型推演，先识别流程，例如入驻流程，然后识别领域事件，例如【门店已联网】，同时明确业务规则，门店一旦有了联网时间不能重置；再识别命令，例如A+开启导致门店联网，同时明确命令执行者是系统，执行时需要查询门店信息。当然可能还有可选领域事件，例如【门店维护人变更】不影响主流程。诸如此类串联完一系列领域事件、命令、查询、执行者之后总结出了【门店】这个领域名词。一个深的体会是过程中的UL语言建立以及结

其实我们日常开发都比较伪DDD，整体实现还是使用 MVC，代码结构类似 Controller、Service、DAO，个人认为这也无可厚非，只是代码的组织形式而已，关键是我们在整体设计时往往缺乏（领域建模-架构设计）这关键两步，很多时候都是就着一个功能点进行（需求分析-数据库 -> 代码实现）。这样没有全局的视角很容易盲人摸象，导致后续摸到一点打个补丁，项目难以维护。DDD的关键不全然是代码架构设计的指导，更是一种应对复杂业务的开发及协作模式，关键人员先通过UL建立有全局共识认知，不确认的地方预留扩展点，再

【代码】【算法训练-二分查找 五】【位置二分】有序数组中的单一元素。

用于将任务请求分发到不同应用服务器，这里可以采用轮询或加权轮询的算法，因为这种速度快，适合抢红包的业务场景;更详细的原文：https://www.infoq.cn/article/2017hongbao-weixin。，将所有数据请求在同一台服务器上进行，防止多台服务器间的不同步问题。微信抢红包架构应该至少包含两个负载均衡，

在设计一个日活跃用户（DAU）达到1000万的论坛的负载均衡集群时，我们需要综合考虑多个方面，包括流量评估、容量规划以及具体的方案设计。

将数据从MySQL同步到Elasticsearch（ES）中并保证一致性是一个常见的需求，特别是在需要快速全文搜索和分析功能的应用中。

根据不同的业务需求和场景，选择适合的数据库类型至关重要。以下是一个优化后的表格展示，涵盖了管理型系统、大流量系统、日志型系统、搜索型系统、事务型系统、离线计算和实时计算七大类业务系统的数据库选型建议。先明确下NoSQL的分类。

实际上，关于Redis事务的说法“Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）”并不完全准确。下面我将分别解释Redis事务的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）和持久性（Durability）。

MySQL主从延迟是指主数据库上的更新操作传输到从数据库并被执行的时间差。通过这些措施，可以有效减少MySQL主从延迟，确保数据的实时性和一致性。

对于简单的单表等值查询，且数据量不大时，MySQL的查询速度可能更快。对于包含大量文本字段的复杂查询或大数据量下的查询，ES的查询速度通常优于MySQL。因此，在单表查询的情况下，ES和MySQL哪个更快并没有绝对的答案。它取决于具体的查询类型、数据量大小、索引策略和系统配置等多个因素。在实际应用中，应根据具体需求选择合适的数据库系统。

Java实现 服务端起10个线程ID监听40-49这10个端口，这10个端口注册到注册中心，提供同一个服务，发个A，响应B，客户端起10个线程去注册中心请求好的，我们可以通过实现一个简单的服务端、注册中心和客户端来达到这个目的。

用多线程来简易的实现一个消息队列的生产者消费者模式：10个线程生成数字消息投递到消息队列，10个线程做数字消息的消费者，消费生产者投递的消息。

低成本本质上是与高性能和高可用冲突的，所以低成本很多时候不会是架构设计的首要目标，而是架构设计的附加约束；安全一般接触不到，功能安全一般框架保证、架构安全一般运营商以及云服务保证；规模其实代表的是业务复杂度的上升对架构的挑战，其实扩展性不好的架构其规模复杂度往往也会随着业务不断升级，所以需要设计扩展性好的架构并且在预测到业务计算及数据规模可能影响正常业务的时候及时进行架构优化。

结合这篇Blog，其实我感觉主要是如何在过度设计与不可扩展间去权衡。长期预测的代价和变数太多，可能在落地前业务就凉了，不做预测又可能刚开始迭代就发现难以支持。所以2年预测是一个经验值，如果到了2年业务发展的好了，会倒逼决策层给资源给钱进行架构升级，如果都用不了2年就凉了那5-10年预测就没意义了；在预测的前提下，我们在方案设计的时候是否可以考虑短、中、长三种方案，短期策略一般考虑的变化少，短视，但迅速，修改小，立竿见影。长期策略一般看重远期，但成本高很高，也很可能预测不中。综合成本情况下如果决定采用短期策略

网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失

性能差-》提升设计复杂度解决性能问题-》掌握如何编码和集群架构cover复杂的设计。高性能复杂度有单机和集群来源。单机主要通过操作系统（多进程、多线程）设计来压榨机器CPU进而提升性能，其设计复杂度体现在需要实现互斥、锁、进程通信等策略，所以要掌握并发编程技术。集群主要是搭建机器集群来扛住大的业务增量，其设计复杂度体现在任务分配（任务分配器、任务分配器与业务服务器连接管理、任务分配算法，其解决系统性能瓶颈的能力随着业务复杂度边际收益逐渐降低）和任务分解（业务逻辑垂直拆分，单项扩展或升级，其系统拆分带来的收益

Rank分层区分系统与子系统暂时隔离关注面，在一个系统层面上，其子系统就是角色Role，子系统之间的关系就是Relation，一个核心的业务流程Rule可能涉及多个子系统的交互。如果子系统就是最小层级业务系统，那么它从逻辑层面讲可能包含很多模块，从部署的角度讲也包含很多组件，单个子系统可以使用springBoot框架搭建，遵守其规范使用其功能；软件架构没有银弹，是以解决系统复杂度为目的而随业务演进的方法论。知道WHAT，WHY，才能更好的学习HOW。

本文是《从零开始学架构》的第一篇学习笔记，在工作6年左右的这个时间点需要有一些先行的理论来指导即将面临的复杂实践，以便在真正面临复杂实践的时候能有所参照。主要从以下几个方面和顺序来进行学习。