<?xml version="1.0" encoding="utf-8" ?><rss version="2.0"><channel><title><![CDATA[来自ZackZhou的善意]]></title><description><![CDATA[]]></description><link>https://blog.youkuaiyun.com/PerfectZC</link><language>zh-cn</language><generator>https://blog.youkuaiyun.com/</generator><copyright><![CDATA[Copyright &copy; PerfectZC]]></copyright><item><title><![CDATA[大白话八股文-MongoDB]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145591516</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145591516</guid><author>PerfectZC</author><pubDate>Wed, 12 Feb 2025 14:41:51 +0800</pubDate><description><![CDATA[其与majority readConcern 比较相似，即，读取「majority committed」的数据，也可能读不到最新的已提交数据，但是其特殊性在于，当用在多文档事务中时，它承诺真正的一致性快照语义。在MongoDB中，当多个事务同时修改同一个document数据时，就会有事务冲突，后面的事务检测到有其他的事务正在修改同一个document数据时，就会抛出WriteConflict写冲突异常，不会执行这个事务，这就是写隔离。集合不需要有相同的结构，即一个集合中的文档可以有不同的字段。]]></description><category></category></item><item><title><![CDATA[Java-分布式架构知识点]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145571644</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145571644</guid><author>PerfectZC</author><pubDate>Tue, 11 Feb 2025 16:18:26 +0800</pubDate><description><![CDATA[领域驱动设计提供了一套完整的理论体系，帮助我们应对复杂业务系统的开发。关键点如下：领域和子域：明确系统边界，按业务模块划分。限界上下文：定义领域模型的边界，与微服务对应。领域对象：实体与值对象结合，贫血与充血模式各有应用场景。聚合：体现整体与部分的关系，聚合根统一管理。工厂与仓库：分别负责对象的创建和持久化。]]></description><category></category></item><item><title><![CDATA[大白话八股文-分布式事务]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145564712</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145564712</guid><author>PerfectZC</author><pubDate>Tue, 11 Feb 2025 14:30:34 +0800</pubDate><description><![CDATA[分布式事务指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。单体系统访问多个数据库多个微服务访问同一个数据库多个微服务访问多个数据库。]]></description><category></category></item><item><title><![CDATA[大白话八股文-Kafka]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145543428</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145543428</guid><author>PerfectZC</author><pubDate>Mon, 10 Feb 2025 10:48:08 +0800</pubDate><description><![CDATA[在消费者客户端中，如果消息进行了压缩，Kafka 会在消费消息时将其解压缩。：保存于索引文件名字上面的起始位移的差值，假设一个索引文件为：00000000000000000100.index，那么起始位移值即 100，当存储位移为 150 的消息索引时，在索引文件中的相对位移则为 150 - 100 = 50，这么做的好处是使用 4 字节保存位移即可，可以节省非常多的磁盘空间。如上图所示，它代表一个日志文件，这个日志文件中有8条消息，0至5之间的消息为已提交消息，5至7的消息为未提交消息。]]></description><category></category></item><item><title><![CDATA[大白话八股文-Redis]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145514933</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145514933</guid><author>PerfectZC</author><pubDate>Sat, 08 Feb 2025 16:13:05 +0800</pubDate><description><![CDATA[首先必须是集群，所以不能是1个。而选举过程要大多数同意才行（即最少一半+1个），而奇数个节点在同样选举条件上可以节省一台机器。比如一共5台，有3台同意了就行；而4台，大多数同意也要3台。一致性Hash算法是对2的32次方取模，什么意思呢？]]></description><category></category></item><item><title><![CDATA[大白话八股文-ElasticSearch]]></title><link>https://blog.youkuaiyun.com/PerfectZC/article/details/145503719</link><guid>https://blog.youkuaiyun.com/PerfectZC/article/details/145503719</guid><author>PerfectZC</author><pubDate>Sat, 08 Feb 2025 11:10:04 +0800</pubDate><description><![CDATA[1）segment: 众所周知，Elasticsearch 存储的基本单元是 shard ， ES 中一个 Index 可能分为多个 shard ， 事实上每个 shard 都是一个 Lucence 的 Index ，并且每个 Lucence Index 由多个 Segment 组成， 每个 Segment 事实上是一些倒排索引的集合， 每次创建一个新的 Document ， 都会归属于一个新的 Segment ， 而不会去修改原来的 Segment；]]></description><category></category></item></channel></rss>