chenglin016的博客

原理：客户端主动发送 Ping 请求，服务端必须回复 Echo 响应，超时未响应则判定服务端离线。原理：客户端定期向服务端发送心跳包，服务端监控客户端存活状态，超时未收到心跳则判定客户端离线。心跳策略优化：可结合 UDP 广播减少连接数，或使用 WebSocket 协议。集群化：将客户端扩展为多节点，服务端通过负载均衡（如Nginx）分发请求。Ping/Echo增强：添加序列号或时间戳，防止重放攻击。停止服务端后，客户端下一次Ping会触发超时。停止服务端后，客户端将在5秒内检测到超时。

redis.setex(“product:123”, 3600, data) # 缓存1小时。SET lock:order 1 NX EX 30 # 获取锁，30秒自动释放。PFADD page:uv “user1” “user2” # 添加用户。避免场景：复杂事务、多表关联查询、大Key（>1MB）。实时消息：List/PubSub（需ACK选专业MQ）大数据处理：HyperLogLog/Bitmap。PFCOUNT page:uv # 估算UV。缓存/会话：优先String/Hash。

布隆过滤器（Bloom Filter）是一种高效的概率型数据结构，主要用于快速判断某个元素‌是否不在集合中‌。示例中当n=1000且p=0.01时，自动计算m≈9585位，k≈7个哈希函数。避免使用加密级哈希函数（如SHA），采用快速非加密哈希。‌缓存穿透防护‌：快速过滤非法请求。‌垃圾邮件过滤‌：初步筛选可疑地址。‌爬虫URL去重‌：避免重复抓取。‌分布式系统‌：减少跨节点查询。‌一、布隆过滤器原理‌。‌三、关键实现细节‌。

3）所在模型即为观察目标，观察目标实现Object接口的3个操作（通知观察者、添加和删除观察者），同时定义一个Observer接口的集合成员。2）运用“面对接口编程思想”，在领域模型内声明接口成员，用接口的处理替代所有的处理分支，接口方法的命名要符合通用语言。6）将转换条件实现在含有状态的模型中（第一个代码例子）或者具体状态类中（第二个代码例子），又或者外部的配置文件中。要综合平衡用户体验和实时性的要求。4）找到事件的消费者，它可能是为了解耦从观察目标拆解出来的新对象，也可能是领域中的其他模型，即观察者。

处于上游的交易系统可能独立于下游系统，而下游系统的开发可能会受到很大的影响，如果不能形成上下游的有效协同，那么下游系统就必须遵从上游上下文的发布节奏来安排自己的工作。这时，下游团队采用的就是追随者模式，完全借用跟随上游发布的模型或接口，下游团队可能必须牺牲其领域模型的清晰性，必须与上游的模型保持一致，通用语言也会因此发生变化，或者借用上游系统的上下文。1）核心域：最具价值、最专业的领域模型的集合，是系统区别于其他系统的独特价值点，体现的是组织的核心竞争力和独特的业务解决之道，如特有的商业模型或核心算法。

作为模型仓库，存储库的另一个实用的功能是扮演仓库管理员，给我们提供关于集合的统计信息，比如对象的数量、集合中所有匹配对象的某个数值属性的总和等。此时，存储库提供的方法不再返回一个聚合根，而是一个值对象。聚合是存储在一个表或多个表中并不重要，重要的是当聚合被持久化时，需要在单个事务中提交，以确保在持文化失败时，聚合不会以不一致的状态被存储。聚合内的规则是时刻不能被违反的，但聚合间的规则要弱一些，所以跨越多个聚合的规则不立刻保持一致是可以接受的（容忍时长取决于业务），我们可以应用最终一致性规则来更新其他聚合。

规格模式是将一组判断条件封装成一个单独的值对象，名称中一般带有形容词，表达了很强的领域含义，代表客户对于程度的看法，如“大额存单”“过期发票”“优秀成绩”等。算法逻辑涉及领域的核心逻辑，其本身往往是内聚的，将其独立出来是最值得倡导的建模实践，如复杂的候选人排名规则、销售佣金的计算策略、保单的风险评估等。算法逻辑独立出来后，避免了复杂算法对领域模型的干扰，领域中的其他模型就可以专注于表达“做什么”的逻辑，而把“如何做”的复杂细节转移给了算法模型。领域事件是领域专家所关心的发生在领域中的有影响力的事件。

为操作独立出一个接口，然后让实现类来实现该接口（取决于你对操作多态性的需要，即是否有不同的操作逻辑需要灵活地替换）领域中的值对象也不需要自己的表，不要为值对象创建单独的表，只需将它们内联到父实体的表中即可。领域服务表示一个无状态的操作，之所以给其单独建模，是因为这类操作不适合放在实体或值对象中。在领域中，一个由身份而不是属性值定义的客观概念就是实体，这个身份可以由一个唯一标识确认。通过所有属性值相同来判断相等的，而不是特定的身份标识符。通过其特性所定义的，它不需要身份，相同特性的值对象是完全等价的。

在执行条的时间范围内，该实体将完成一系列操作，这些操作都是同步的，意味着一个操作有了返回值才会执行下一个操作，执行条消失意味着该实体的方法执行完毕。一般在没有自动垃圾回收机制的语言中需要考虑销毁对象的操作，如果我们使用的是完全的面向对象语言，如Java、C#，则可以忽略销毁对象的操作。”的关系，代码层面对应的是集合，也可以添加相应的业务逻辑，比如如果集合是排好序的，可以加上{Ordered}特性。被创建的对象与创建它的对象不在同一高度，时序图从上到下体现的是时间顺序，低于被创建者，意味着它是之后被创建的。

1：语义一致性（Semantic Coherence）原则：相同的逻辑，代码中只能有一个处理的地方。（DDD）所有的业务逻辑都必须封装在领域模型中，领域模型是调用业务逻辑的唯一入口，保证了“一处逻辑只有一处代码”的原则。3：最简（Minimize）原则：用最简单的机制来满足需求，不要引入不必要的组件、框架等，用极简的方式添加功能，2：开闭（Open-Closed）原则：软件模块对于需求应该是可以扩展的，但对于代码修改是关闭的。高内聚即关系紧密的逻辑整体要组织到一起，每个模块都要有清晰定义的角色，

熔断机制类似于电路中的熔断器，当某个服务出现故障或响应时间过长时，熔断器会“熔断”，阻止后续请求继续访问该服务，从而避免整个系统的崩溃。1）一致性（C）：是指分布式系统中的所有数据副本在同一时刻是否一致，也就是说，访问所有数据副本的节点，是否都会返回一样的结果。3）分区容错性（P）：这个概念比较抽象，简单来说，假设集群有两个节点对外提供服务，理论上，这两个节点之间是可以互相通信的，例如，如果阈值设置为每分钟10个请求，且所有请求都在时间窗口的最后几秒内到达，那么这些请求仍然会被接受，可能导致系统过载。

4）Elasticsearch用来处理用户针对请求日志的查询请求，它将查询关键字段的值和请求ID存放到索引中，跟进查询关键字获得结果ID的列表，再通过结果ID去HBase中获取详细的请求数据。可以把Kafka的存储架构简单理解为，Kafka写数据时通过追加数据到文件末尾来实现顺序写，读取数据时直接从文件中读，这样做的好处是读操作不会阻塞写操作，这也是其吞吐量大的原因。总体来说，对于浏览页面的用户行为，需要把用户请求尽量拦截在CDN、静态资源或负载均衡侧，如果确实做不到，也要拦截在缓存中。

假设需要查询的数据分布在多个数据库的多个表中（比如在order1里面的t_order_1，order2里面的t_order_9中），那么需要将针对这些表的查询结果合并成一个数据集。比如，原来有2000万的数据，设计10个分区，每个分区存200万的数据，那么可以优化查询语句，让它只去查询其中两个分区，即只需要扫描400万的数据。2）用户能接受新旧数据分开查询，比如有些电商网站默认只让查询3个月内的订单，如果要查询3个月前的订单，还需要访问其他的页面。同样，有新数据时，可以增加更多的分区来存储新数据。