Case Analysis
DDD, Hexagonal, Onion, Clean, CQRS, … How I put it all together
Redis与MySQL双写一致性：延迟双删binlog异步删除
解释器和规则系统图解 dbms && nosql && redis 延迟双删 令 单线程模型:Redis是单线程模型的，而单线程避免了CPU不必要的上下文切换和竞争锁的消耗。 也正因为是单线程，如果某个命令执行过长(如hgetall命令)，会造成阻塞。Redis是面向快速执行 场景的数据库。，所以要慎用如 smembers和Irange、hgetall等命令 如何解决热key问题? Redis集群扩容:增加分片副本，均衡读流量; 将热key分散到不同的服务器中; 使用二级缓存，即JVM本地缓存,减少Redis的读请求。 redis过期策略和内存淘汰策略 定时、定期、惰性 内存淘汰策略：LRU(Least Recently Used)、LFU(Least Frequently Used)、 redis持久化机制有哪些？优缺点是什么？ 如何实现高可用？ redisson 解决分布式锁的问题 redlock算法 mysql与redis如何保证双写一致 redis6.0 多线程 redis事务处理 redis哈希冲突 管道-过滤器的并行优势，核心是通过“流水线重叠+多实例并行+分布式部署”三层机制实现，完全依托架构本身“过滤器独立、数据流单向流动”的天然特性，不需要复杂的共享状态协调。 黑板系统中知识源的协作，核心是完全不直接通信，所有交互都通过共享黑板+控制器调度完成，像医院急诊室的多科室医生围绕同一份电子病历协同诊断，最终逐步收敛出问题的完整解。 解释器和规则系统图解 ## 软件设计方法 DDD (Domain Driven Design) 领域驱动设计 CQRS (Command Query Responsibility Segregation) 命令查询分离 Hexagonal Architecture Onion Architecture WPDRRC信息安全模型 SysML (System Modeling Language) 系统建模语言 MBSE (Metamodel-Based Software Engineering) 基于元模型的软件工程 ## 五大架构风格 1.数据流风格: 2.调用/返回风格: 3.独立风格: 4.虚拟机风格: 5.仓库风格: ## 八大架构 1.信息系统架构 2.层次式架构 3.云原生架构 4.面向服务架构 5.嵌入式系统架构 6.通信系统架构 7.安全架构 8.大数据架构 六边形架构 (Hexagonal Architecture) 物理层：比特传输，保证比特传输的可靠性， 协议有：RS232, RS485, RJ45, FDDI, 数据链路层： 比特组成帧，是帧与帧之间的传输，进行差错控制和流量控制,协议有：IEEE 802.3 802.5 802.11、ATM 网络层：报文传输，路由选择和报文控制，协议有：IP、ARP、RARP、ICMP 传输层：提供端到端报文的可靠、透明传输，保证报文的传输顺序正确性和完整性, 协议有：TCP、UDP 会话层：提供进程间的会话同步。对应80、443端口 表示层：提供数据格式转换，如：ASCII、BMP、JPEG 应用层：为用户提供服务，协议有：HTTP、FTP、SMTP、POP3、IMAP
架构风格
虚拟机风格：构建“虚拟执行环境”，按规则或解释逻辑处理任务。 * 解释器：解释执行自定义代码，典型如JVM、Python解释器。执行效率低但灵活。 * 基于规则的系统：通过规则集推理决策，典型如专家系统、DSS决策支持系统。 仓库风格（以数据为中心）：所有构件围绕共享数据存储协作。 * 数据库系统：构件通过SQL访问中央数据库，典型如电商订单系统。 * 黑板系统：多个知识源围绕黑板异步读写，共同解决问题，适合没有确定性算法的复杂问题, 典型如语音识别、图像处理。 ### 管道-过滤器的并行优势， 核心是通过“流水线重叠+多实例并行+分布式部署”三层机制实现 并行的前提：过滤器无状态、单一职责、接口标准化，这是架构天生的优势 典型考法： 问“编译器的词法分析、语法分析、代码生成三个阶段为什么能高效并行”， 答案就是管道-过滤器的流水线重叠并行 管道-过滤器：数据边流动边加工，像“流水线”。典型例子：传统编译器、网络报文处理、路由器、防火墙。 管道-过滤器是流式数据、可并行 第一层：流水线式时间重叠并行 这种并行让多个过滤器在同一时间片内同时工作，把原本串行的总耗时从T1+T2+T3压缩到接近最慢单个过滤器的耗时。 第二层：多实例数据并行 * 由于过滤器之间不共享状态、只通过标准化管道交互，同一个过滤器可以启动N个完全相同的实例，把输入数据流分片后分发给这些实例并行处理。 * 典型场景：日志清洗流水线中，“日志解析”这个过滤器启动10个实例，把Kafka的10个分区分别交给一个实例消费，整体吞吐量直接提升10倍。 * 这种并行没有锁竞争、没有状态同步开销，扩展成本极低，是大数据流式处理（Flink/Spark Streaming）的核心加速手段。 第三层：分布式跨节点并行 * 过滤器之间完全解耦，只依赖管道传输标准化数据流，天然支持把不同过滤器部署在不同的服务器、甚至不同机房的节点上。 * 比如ETL流水线：“数据提取”跑在数据源所在的业务服务器，“数据清洗”跑在计算集群的CPU节点，“数据加载”跑在数仓所在的存储节点，三个节点完全并行工作，没有单点性能瓶颈。 * 华为云等云原生架构实践中，这种分布式部署方式可以根据每个过滤器的负载单独弹性扩缩容，资源利用率远高于单体串行系统。 ### 黑板系统 黑板系统中知识源的协作，核心是完全不直接通信，所有交互都通过共享黑板+控制器调度完成，像医院急诊室的多科室医生围绕同一份电子病历协同诊断，最终逐步收敛出问题的完整解。 协作的三大核心角色 所有协作都围绕三个固定组件展开，没有任何知识源之间的点对点调用： * 黑板：全局共享的分层数据区，存储原始问题、中间结果、最终结论，按层级划分子区域，避免读写冲突。 * 知识源：每个都是独立的“领域专家”，只拥有自己专属的专业能力，比如语音识别里的“音素识别源”“词语匹配源”“语法分析源”，互不依赖对方的内部逻辑。 * 控制器：全局调度中心，监控黑板状态，决定下一个激活哪个知识源，避免并发读写冲突，推进求解流程。 ### 解释器和规则系统 - 结合金融风控的实践写一篇论文 解释器和规则系统同属虚拟机风格，核心区别是 解释器聚焦“按流程逐行执行自定义代码”， 规则系统聚焦“按条件动态匹配规则推理决策”， 二者在运行逻辑、核心组件、适用场景上完全不同。 1.执行效率：解释器逐行翻译执行，效率远低于原生编译代码；规则系统通过Rete算法优化规则匹配，在大量规则场景下推理效率远高于硬编码的if-else分支。 2.维护成本：解释器修改逻辑必须改源代码；规则系统只需要修改规则集，完全不用动程序代码，非技术人员也能维护。 典型考题区分：看到“脚本语言、跨平台、逐行执行”选解释器；看到“专家系统、决策推理、如果-那么规则”选规则系统。 核心运行逻辑差异 * 解释器：像同声传译，严格按代码的书写顺序逐行执行，有明确的执行流和程序计数器，每一步操作都由源代码的顺序决定，不会主动跳转或回溯。比如Python解释器运行脚本，完全按代码从上到下的顺序执行，不会跳过某行自动执行其他逻辑。 * 规则系统：像经验丰富的法官，没有固定执行流，通过“匹配-执行”循环工作：先扫描所有规则，找出条件被当前事实满足的规则，执行后更新事实，再触发新一轮规则匹配，动态迭代推理出结果。比如医疗诊断专家系统，不会按固定顺序跑代码，而是根据输入的症状自动匹配对应的诊断规则。 | 维度 | 解释器 | 规则系统 | | 核心组件 | 解释引擎、代码存储区、状态记录器、执行进度跟踪器 | 规则集、规则解释器、规则/数据选择器、工作内存 | | 核心数据 | 待执行的源代码/字节码 | 大量“如果-那么”形式的规则库 + 动态事实数据 | | 调度逻辑 | 按程序计数器顺序推进执行 | 用Rete等算法动态筛选优先级最高的规则执行 | 典型应用场景差异 * 解释器：适合需要跨平台执行自定义程序的场景，比如Python/JVM等脚本语言引擎、领域特定语言（DSL）实现、配置文件动态解析。核心价值是弥合自定义语言和底层硬件的语义差异，实现“一次编写，到处运行”。 * 规则系统：适合需要大量专业知识做决策的场景，比如医疗诊断专家系统、金融风控引擎、保险理赔系统、电商促销规则配置。核心价值是把业务规则和代码完全分离，业务人员不用改代码就能直接修改规则，快速响应需求变化。 规则系统架构在金融风控中的落地，核心是把风控决策逻辑从硬编码代码中完全抽离， 通过“规则可视化配置+全生命周期闭环管控”实现业务策略的秒级迭代， 既满足金融行业强合规要求，又能快速响应监管政策和风险场景的变化。
RocketMQ vs Kafka
1 RocketMQ * RocketMQ的系统设计更偏向于队列模型，提供了丰富的消息队列语义，如顺序消息、事务消息和定时消息等。 * 它主要由NameServer、Broker、Producer和Consumer组成。NameServer负责服务注册与发现，Broker负责存储消息，Producer和Consumer分别负责发送和消费消息。 * RocketMQ还支持Filter Server组件，用于支持消息过滤功能。这种设计使得RocketMQ在处理复杂业务逻辑时更加灵活。 2 Kafka * Kafka的系统设计更偏向于日志模型，强调数据的顺序性和持久性。 * 它主要由Producer、Consumer、Broker和ZooKeeper（或KRaft）组成。 Producer和Consumer分别负责发送和消费消息，Broker负责存储消息，ZooKeeper（或KRaft）负责协调管理。 * Kafka的Broker是无状态的，可以独立处理请求，并通过ZooKeeper（或KRaft）进行协调管理。这种设计使得Kafka在处理高吞吐量日志数据时更加高效。 相同之处 1.分区机制：消息通过 rocketmq queue/kafka partition 进行分区，提高了消费者并行处理能力 2.副本机制：通过对分区进行副本 replication，提升了容灾能力 3.页缓存：两者均利用了操作系统的页缓存 Page Cache 机制，加载数据时，以该数据所在的页提前缓存到操作系统内存中，从而实现相邻数据的快速访问 4.顺序 IO：两者都尽可能通过顺序 IO 降低读写的随机性，将读写集中在比较集中的区域，从而减少缺页中断，提高了性能 5.零拷贝：都使用零拷贝降低用户空间和内核空间的转换以及 CPU 的利用率，但是在具体使用上仍然有差异 6.单分区有序：都仅支持单Topic分区有序，全局有序也是基于使用单个分区 7.消息压缩：都支持对消息压缩，减少网络传输数据量 RocketMQ更适合需要丰富队列语义和灵活消费模式的场景； 而Kafka则更适合强调数据顺序性、持久性和高吞吐量的日志处理场景。 Kafka 吞吐快，适合数据流处理相关的场景，没有比较复杂的业务处理，比方说常用的日志处理，或者涉及到 Hive、Spark、Flink 等大数据等场景，字节内部的 Dorado 数据转换平台使用的就是 Kafka，能够实现 Hive 表转 Kafka 消息 复杂业务场景下尽量用 RocketMQ，RocketMQ 本身性能也不低，而且还有许多业务上能用到的功能特性。