MayMatrix 的博客

如果我们采用了CQRS模式，但是命令和查询两侧底层所依赖的数据模型并未分离，而是基于共享的数据存储和数据模型，命令和查询之间不需要额外的交互，命令侧的数据更新对查询侧实时可见。命令侧负责数据的更新，而查询侧只负责数据的查询，如何将数据的更新及时同步到查询侧是需要解决的问题。但是不幸的是，我们丢失了历史信息，包括用户的意图信息。往往采用CQRS后，查询和命令两侧会采用独立的数据模型，在这种架构模式下，命令侧的数据变化后及时同步到查询侧，两侧数据并非实时，在一定的延时后两侧数据最终达成一致。

定义 ”架构是什么“ 是件非常困难的事情，不同的组织对于软件架构有不同的定义，每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图一样，对架构进行完备的定义是不可能的。行业内不同的组织和个人从不同的视角对 “什么是架构” 进行了阐述。IEEE 关于架构的定义components, their, and theprinciples将系统架构定义为：架构是系统组织结构组件及联系（组件间以及组件和环境之间）原则的组合。

架构设计方法论是指导你如何来做架构设计，它有架构域划分，在软件设计中架构域包括：业务架构、数据架构、产品架构、应用架构、技术架构 ，首先需要进行业务需求结合业务场景的梳理，熟悉业务后，通过归纳以及抽象的方式，形成业务架构，依据业务架构的理解，研发人员需要对业务做进一步的抽象和沉淀，画出与之相对应的数据架构和应用架构，最后技术人员通过技术架构来做功能实现。这些都是有很多种可能性的架构方案，解决一个软件复杂度问题方案，有方案A，方案B，甚至有方案C 应该用哪个，原因是什么，都是架构设计需要思考的问题；

也许您对软件设计存在一些疑惑，或者缺乏明确思路，那么本文将非常适合您。。

良好的模块化是单体走向微服务的重要基石，如果模块化设计较差的系统，不仅会增加微服务拆分的成本，更为重要的是，会增加形成分布式单体的概率和风险。技术视角是研发友好的，作为开发人员，天然的可以理解和接受这种技术维度的统一语言：DAO层只负责处理数据相关逻辑，Controller层之服务处理Restful API相关，RPC层只处理与外部系统的跨进程调用等等。首先会想到的例子，比如，如果底层的数据库发生了变更，又或者ORM框架发生了变更，那么，我们只需要修改DAO层的实现，而不需要更改上层的业务层代码。

金融核心等业务可能会选择 TCC 方案，以追求强一致性和更高的并发量，而对于更多的金融核心以上的业务系统 往往会选择补偿事务，补偿事务处理在 30 多年前就提出了 Saga 理论，随着微服务的发展，近些年才逐步受到大家的关注。如果你要操作别的服务对应的库，不允许直连别的服务的库，违反微服务架构的规范，你随便交叉胡乱访问，几百个服务的话，全体乱套，这样的一套服务是没法管理的，没法治理的，可能会出现数据被别人改错，自己的库被别人写挂等情况。这个的意思，就是干脆不要用本地的消息表了，直接基于 MQ 来实现事务。

在 GetBrandNameCommand 中，run() 方法的正常逻辑是去调用品牌服务的接口获取到品牌名称，如果调用失败，报错了，那么就会去调用 fallback 降级机制。我们现在有个包含 brandId 的商品数据，假设正常的逻辑是这样：拿到一个商品数据，根据 brandId 去调用品牌服务的接口，获取品牌的最新名称 brandName。假如说，品牌服务接口挂掉了，那么我们可以尝试从本地内存中，获取一份稍过期的数据，先凑合着用。// 如果调用失败，报错了，那么就会去调用fallback降级机制。

eBPF，它的全称是“Extended Berkeley Packet Filter”。从名字看，你可能会觉奇怪，似乎它就是一个用来做网络数据包过滤的模块。其实这么想也没有错，eBPF 的概念最早源自于 BSD 操作系统中的 BPF（Berkeley Packet Filter），1992 伯克利实验室的一篇论文 “The BSD Packet Filter: A New Architecture for User-level Packet Capture”。

因为公司的开放网关的限流模块就是基于Redisson开发的，之前看的版本源码与最新的已经有很大的不同，趁着整理知识点的机会下了最新版的源码看了一遍。限流这个说简单也简单，说复杂也复杂。不知道是不是我看的东西太少，我觉得redisson的限流器设计非常精巧，感觉把redis玩穿了。

本文主要介绍了Java中4种经典限流算法讲解，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧−目录最近，我们的业务系统引入了Guava的限流组件，它是基于实现的,而令牌桶是非常经典的限流算法。本文将跟大家一起学习几种经典的限流算法。

hotkey项目地址:https://gitee.com/jd-platform-opensource/hotkey 在拥有大量并发用户的系统中，热key一直以来都是一个不可避免的问题。或许是突然某些商品成了爆款，或许是海量用户突然涌入某个店铺，或许是秒杀时瞬间大量开启的爬虫用户， 这些突发的无法预先感知的热key都是系统潜在的巨大风险。 风险是什么呢？主要是数据层，其次是服务层。 热key对数据层的冲击显而

REDIS缓存穿透，缓存击穿，缓存雪崩原因+解决方案一、前言在我们日常的开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫

读完需要10分钟 速读仅需 5 分钟卫向军，现任三好网联合创始人及CTO，主要负责K12领域的直播互动教学服务平台和教育O2O系统。曾在微软、金山、新浪微博从事技术研发管理工作，分别担任过架构师、技术总监以及CTO，有丰富的技术、产品、设计、测试团队管理经验，既熟悉外企里规范化、标准化、流程化的团队项目管理，也了解如何打破常规实现创新项目的短平快上线，在矩阵式团队管理上颇有心得。原文地址：http://www.cnblogs.com/shanyou/p/5048099.html架..

相传魏文王和名医扁鹊之间曾经发生过这样一段对话：魏文王：“你们兄弟三人，谁是医术是最好的呢? ”扁鹊：“大哥最好，二哥差些，我是三人中最差的一个。”魏文王：“那为什么你的名气最大？”扁鹊：“大哥治病，是治病于病情发作之前，病人尚未发病即已根除病因，使得他的医术没有得到认可，没什么名气；二哥治病，是治病于病情初起时，二哥药到病除，大家认为二哥善治小病，名气只在本乡里；而我是治病于病情严重之时，大家看到我或在经脉上穿刺放血，或在患处敷以毒药以毒攻毒，或动大手术直指病灶，使重病人病情得到缓解或治愈

如果你在做选型方面的工作，或者想了解一些现在正在流行的技术，那么这篇文章正好适合你。图片来自 Pexels本篇内容涵盖 14 个方面，涉及上百个框架和工具。会有你喜欢的，大概也会有你所讨厌的家伙。这是我平常工作中打交道最多的工具，大小公司都适用。如果你有更好的，欢迎留言补充： 消息队列 缓存 分库分表 数据同步 通讯 微服务 分布式工具 监控系统 调度 入口工具 OLT...

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。什么是事务介绍分布式事务之前，先介绍什么是事务。事务的具体定义事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常

- 刚性事务总结 -在《分布式架构之设计篇-刚性事务之2PC详解》和《分布式架构之设计篇-刚性事务之3PC详解》二文中分析了分布式事务的本质、XA、2PC、3PC等等。但是没有说分布式事务的现象或者场景，我总结了分布式事务的触发场景大约有以下几种：1、跨数据库分布式事务：数据库的物理分割下保障跨库操作的ACID。2、跨服务分布式事务：服务的网络分割下保障多服务的事务完整性。3、混合式分布式事务：跨数据库分布式事务 + 跨服务分布式事务。最根本的原因就是事务参与者出现...

分布式一致性分布式场景下，多个服务同时对服务一个流程，比如电商下单场景，需要支付服务进行支付、库存服务扣减库存、订单服务进行订单生成、物流服务更新物流信息等。如果某一个服务执行失败，或者网络不通引起的请求丢失，那么整个系统可能出现数据不一致的原因。上述场景就是分布式一致性问题，追根到底，分布式一致性的根本原因在于数据的分布式操作，引起的本地事务无法保障数据的原子性引起。分布式一致性问题的解决思路有两种，一种是分布式事务，一种是尽量通过业务流程避免分布式事务。分布式事务是直接解决...

- 起源 -Saga模型起源于1987年 Hector Garcia-Molina，Kenneth Salem 发表的论文《Sagas》，是分布式事务相关概念最早出现的。Saga模型是把一个分布式事务拆分为多个本地事务，每个本地事务都有相应的执行模块和补偿模块（对应TCC中的Confirm和Cancel），当Saga事务中任意一个本地事务出错时，可以通过调用相关的补偿方法恢复之前的事务，达到事务最终一致性。- 组成 -Saga模型主要分： ...

概述在微服务时代，注册中心越来越被重视。服务治理逐渐跟业务服务并驾齐驱。所以本文想对注册中心进行体系化探索。注册中心，起源于分布式时代。不管是水平拆分架构，或者垂直拆分架构，对于多服务、多实例的支持，都需要对服务进行治理。注册中心被用于服务治理中的服务注册、服务发现、服务探活等场景。架构师需要追寻事物的本质，并做好设计平衡，才能真正做到降本增效。那么注册中心的本质是什么：1、根据服务发现的需求反推出第一个本质是一个Query函数Si = F(serviceName) serv...

微服务兴起的这几年涌现出不少分布式事务框架，比如ByteTCC、TCC-transaction、EasyTransaction以及最近很火爆的Seata。最近刚看了Seata的源码（v0.5.2），借机记录一下自己对分布式事务的一些理解。（3年前这类框架还没成熟，因项目需要自己也写过一个柔性事务框架）。本文分五部分，首先明确分布式事务概念的演变，然后简单说下为什么大家不用XA，第三部分阐述两阶段提交的“提升”，第四部分介绍Seata的架构的亮点与问题，第五部分谈下分布式事务的取舍。限于篇幅...

分布式事务分布式事务是指事务的参与者，支持事务的服务器，资源服务器分别位于分布式系统的不同节点之上，通常一个分布式事物中会涉及到对多个数据源或业务系统的操作。典型的分布式事务场景：跨银行转操作就涉及调用两个异地银行服务CAP理论CAP理论：一个分布式系统不可能同时满足一致性，可用性和分区容错性这个三个基本需求，最多只能同时满足其中两项一致性(C)：数据在多个副本之间是否能够保持一致的特性。可用性(A)：是指系统提供的服务必须一致处于可用状态，对于每一个用户的请求总是在有限的时间内返回

一致性Hash负载均衡算法实现1. Hash函数要将对象和服务器映射到Hash环中，需要计算出来哈希码，这就需要有Hash函数来完成，也就是关系到使用的哈希算法。使用一个好的哈希算法是很重要的，为什么这么说呢，拿我们上面提到的缓存服务来说，一个完美的解决方案是需要数据分配的平衡，假如Hash环的映射是这样的：哈希码聚集.jpgHash码数值落在一个小区间内，出现Hash码聚集情况，那么从上图可以看到缓存数据全部由c3节点的服务器存储，出现数据分配不平衡。那么就需要一个好的哈希处理使得哈希

分布式系统中一致性哈希算法业务场景近年来B2C、O2O等商业概念的提出和移动端的发展，使得分布式系统流行了起来。分布式系统相对于单系统，解决了流量大、系统高可用和高容错等问题。功能强大也意味着实现起来需要更多技术的支持。例如系统访问层的负载均衡，缓存层的多实例主从复制备份，数据层的分库分表等。我们以负载均衡为例，常见的负载均衡方法有很多，但是它们的优缺点也都很明显：随机访问策略。系统随机访问，缺点：可能造成服务器负载压力不均衡，俗话讲就是撑的撑死，饿的饿死。 轮询策略。请求均匀分配，如果服

- 总述 -咱们前面分别对分布式事务的几个分支：XA、2PC、3PC、TCC、Saga、事务消息、最大努力事务进行的详细介绍。本篇作为分布式事务设计的收尾篇，讲对前面的内容查缺补漏和总结，最后对市面的一些开源框架做一些介绍。- 查缺补漏 -1.补偿型事务柔性事务分补偿型事务和通知型事务。但对补偿型事务没有进行详细介绍，那什么是补偿型事务呢，在Atomikos 公司Guy Pardon的论文《Business_Activities》中有这样的描述：...

一、背景研究了grok几天，虽然知识还是很浅薄，但还是在这里做个总结。场景在使用logstash进行日志收集工作的时候，filter是个很重要的插件，而其中的Grok能很好的解析日志。logstash教程：https://blog.csdn.net/qq_34646817/article/details/81232083grok教程：https://blog.csdn.net/q...

在整理项目的时候，突然发现对数据库的水平切分与垂直切分比较模糊，特此学习！参考：https://www.cnblogs.com/bluebluesky/articles/6413831.html1、数据库分区就是把同一个数据库里的表放到不同的服务器上，负载均衡，但是在用户上来看，只有一个服务器2、数据库分表把一张表按照一定的规则分解成不同的实体表。比如垂直划分和水平划...

一、AKF拆分原则　　业界对于可扩展系统架构设计有一个朴素的理念：通过加机器就可以解决容量和可用性问题。　　这一理念在云计算概念疯狂流行的今天，得到了广泛的认可，对于一个规模迅速增长的系统而言，容量和性能问题当然是首当其冲的。但随着时间的向前，系统规模的增长，除了面对性能与容量的问题外，还要面对功能与模块数量上的增长带来的系统复杂性问题以及业务的变化带来的提供差异化服务的问题。　　然而...