- 博客(169)
- 收藏
- 关注
RSS订阅原创 Apache Pulsar 消息、流、存储的融合
消息队列在大层面有两种不同类型的应用，一种是在线系统的message queue，一种是流计算，data pipeline的streaming高throughout，一致性较低，延迟较差的过程。存算分离 扩容和缩容快速segment 打散（时间和容量切分）多机器能力多租户的能力，配额原来的架构，多种消息中间件不同场景不同选型统一兼容旧系统协议，统一存储bookkeeper内部二级分层存储，统一批存储和流存储（之前外部系统计算存储到HDFS）
2025-05-14 17:33:38
387
原创 从Aurora 架构看数据库计算存储分离架构
单就公有云来说，现在云数据面临的挑战有以下 5 个：跨 AZ 的可用性与数据安全性。现在都提多 AZ 部署，亚马逊在全球有 40 多个 AZ， 16 个 Region，基本上每一个 Region 之内的那些关键服务都是跨 3 个 AZ。你要考虑整个 AZ 意外宕机或者计划内维护要怎么处理，数据迁移恢复速度怎么样。以传统的 MySQL 为例，比如说一个机器坏了，可能这个机器上存了几十 T、上百 T 的数据，那么即使在万兆网卡的情况下，也要拷个几分钟或者几十分钟都有可能。那么有没有可能加快这个速度。
2025-05-13 12:38:01
674
原创 异地多活单元化架构下的微服务体系
金融要求，距离太远，异地备库，如果延迟没读到数据就可能有资损，IDC3平时不能用，IDC1挂了还是有数据同步问题，IDC3日常维护也有问题（平时没运行）OceanBase paxos多副本，地域业务优先级选举，在多大数副本ok情况下可用。1.只保证核心业务 AP (CAP是数据维度观点，一个系统可以AP数据和CP数据)如何减少单元调用，一层一层做，越早越好，最后数据库层一定要兜底。某个单元挂了怎么办，如何做主备库，还是要主备库分开部署。数据库很多需要同步，消息队列很快，核心业务同步。从业务角度看异地多活。
2025-05-10 21:27:04
489
原创 广告事件聚合系统设计
规模上 10000 0000个点击（10000 00000 / 100k 1wQPS） 100 0000 0000 展示 （100wQPS） CTR 1%左右。2.cassdread indisk（3M（峰值，如果可以弹性加的话可以少点） / 15k 200node） 不是很大的集群规模。所以我们需要由数据接入，数据处理，数据存储，数据查询等多个服务模块去支持我们的广告系统。3，redis in memory (贵且容易丢数据，集群规模小)3M / 100k 30node。
2025-05-02 21:49:26
918
原创 云盘系统设计
冷数据归档是优化存储成本、提升数据库性能的关键技术手段，其实践需结合业务场景和技术方案综合设计。冷数据归档是优化存储成本、提升数据库性能的关键技术手段，其实践需结合业务场景和技术方案综合设计。本质差异协议本质：长轮询是 HTTP 的变种，WebSocket 是独立协议，SSE 是 HTTP 流37。核心差异：通信方向（单向/双向）、实时性、资源开销35。选型原则：根据实时性需求、技术栈兼容性、服务器资源综合决策57。3.md5在判断什么完整性MD5在文件分片传输场景中用于验证。
2025-05-02 20:22:30
967
原创 Go与Cpp的本质区别
维度Go 语言特性C++ 语言特性内存管理自动垃圾回收手动管理或智能指针并发模型Goroutines + Channels（轻量级）线程 + 锁（重量级）语法复杂度简洁、强约束复杂、高灵活性编译速度快速较慢（尤其大型项目）运行时性能适合高并发 I/O适合计算密集型任务应用领域Web 后端、云原生系统编程、游戏引擎、嵌入式通过上述对比，可依据项目需求（性能、开发效率、安全性等）在两者间做出选择但是造成这个不同问题背后的原因是什么？
2025-04-30 11:00:47
831
原创 全局id生成器生产方案
中心式的解决方案实现简单，但是跨区域的性能损耗大，因此实际部署时，会将 PD 集群部署在同一个区域，避免跨区域的性能损耗。PD 的 TSO 授时工作是由集群中 leader 来完成的。此外，PD 通过引入 etcd 解决了单点的可用性问题，一旦 leader 节点故障，会立刻选举新的 leader 继续提供服务，理论上来讲由于 TSO 授时只通过 PD 的一个 leader 提供，所以可能是一个潜在的瓶颈，但是从目前使用情况看，PD 的 TSO 分配性能并没有成为过 TiDB 事务中的瓶颈。
2025-04-29 20:51:27
800
原创 Spark知识总结
宽窄依赖：父RDD的分区只对应下面子RDD的一个分区，为窄依赖。如果被传到多个子RDD分区，就需要。父RDD的一个分区会被传到几个子RDD分区。如果被传到一个子RDD分区，就可以。
2025-04-28 20:22:48
401
原创 ClickHouse 设计与细节
ClickHouse 是一款备受欢迎的开源列式在线分析处理 (OLAP) 数据库管理系统，专为在海量数据集上实现高性能实时分析而设计，并具备极高的数据摄取速率 1。其在各种行业中得到了广泛应用，包括众多知名企业，例如超过半数的财富全球 2000 强公司都信赖 ClickHouse 来处理其生产工作负载 1。值得注意的是，在 2024 年，ClickHouse 的设计与架构以一篇名为 “ClickHouse - Lightning Fast Analytics for Everyone” 的论文形式发表于国际
2025-04-22 16:35:52
972
原创 实时直播弹幕系统设计
整个服务读多写少，读写比例大概几百比1.如果实时性要求高的话，可以采用长连接模式（轮询的话，时效性不好，同时对于评论少的直播间可能空转）websocket 和 SSE架构只要求服务端推送的话，可以选SSE，评论还是少量的，减少资源的浪费长连接选型单体架构发布订阅模式去推送消息到SSE,会导致无用的消息，浪费大量SSE资源按直播间分区，然后消费，可以缓解问题，但没有解决问题多个topic 动态 直播间。对元数据服务比如zookeeper的压力？
2025-04-18 20:06:52
943
原创 大数据调度组件
分离资源管理（RM）与应用逻辑（AM），支持多计算框架（如MapReduce、Spark）。预分队列资源（如A队列80%、B队列20%），允许弹性抢占（如B队列白天可占100%）。2. 资源利用率高：动态分配减少空闲 2. 资源模型较简单（仅CPU/内存）。容器配置：优化Container内存/CPU分配，避免OOM或资源碎片。统一资源池化管理，通过动态分配提升利用率（如空闲资源跨队列借用）。调度器参数：调整容量调度器的最大资源占比、最小资源保障。
2025-04-17 20:42:39
407
原创 交易中台代码解析（TODO）
完整的微服务架构，集成了SpringCloud、Eureka、Feign等组件。- 采用领域驱动设计(DDD)思想，清晰划分了购买域、履约域、售后域和结算域。这个项目对于想要学习企业级应用架构设计和实现的人来说，是一个很好的参考案例。- 实现了业务能力和领域能力的分离，提高了系统的可维护性和扩展性。- 多数据源和分库分表支持，使用Sharding-sphere。- 分布式锁、分布式ID、重试机制等基础组件的抽象和实现。- 分布式重试机制：支持自动重试和延迟队列重试。- 通过扩展点引擎支持业务差异化。
2025-04-15 22:10:54
140
原创 大厂文章阅读
1.1)任务失败如何处理(CAS失败也可用)：1.指数退避,匹配下游任务执行系统的处理能力。比如收到下游任务执行系统的流控错误，或者感知到任务执行成为瓶颈，需要指数退避重试。不能因为重试反而加大了下游系统的压力，压垮下游。反压控制，或者类似于flink基于credit 双向同步 的流空机制2.重试的策略要简单清晰，易于用户理解和配置。首先要对错误进行分类，区分不可重试错误，可重试错误，流控错误。不可重试错误是指确定性失败的错误，重试没有意义，比如参数错误，权限问题等等。
2025-04-11 21:07:17
701
原创 如何设计好一张表
最终目标是通过这些“微小”的字段，构建出健壮、可观测、易维护的数据资产体系。ABA问题防御：高并发场景下，通过update_time作为乐观锁版本号，避免并发覆盖（伪代码：UPDATE table SET col=new_val WHERE id=1 AND update_time=old_update_time）。默认值策略：create_time/update_time默认由数据库自动填充（如MySQL的DEFAULT CURRENT_TIMESTAMP），而非应用层写入，避免时区问题。
2025-04-04 13:07:14
406
原创 杂记。。。
CRDT通过数学严谨的数据结构设计，为分布式系统提供了去中心化高可用的解决方案，但其落地需权衡内存开销、时钟一致性和业务操作约束。在Redis等数据库场景中，需结合具体命令特性选择CRDT类型，并设计配套的冲突解决与垃圾回收机制多租户实现需根据场景平衡隔离粒度与资源成本轻量级场景可采用字段隔离或单库多租户12；高要求场景建议物理隔离或Kubernetes CRD管理34。QoS设计需聚焦资源公平性与SLA保障，通过动态策略提升系统弹性4。
2025-02-27 16:38:02
961
原创 各种协议设计
这篇论文《End-to-End Arguments in System Design》由J.H. Saltzer、D.P. Reed和D.D. Clark撰写，首次发表于1981年，是计算机系统设计领域的经典文献之一。端到端原则是系统设计中的一种“奥卡姆剃刀”原则，它指导设计者将功能放置在最适合的层次（通常是应用层）。因此，通信子系统的可靠性功能只能减少应用层的重传次数，而不能替代应用层的功能。：只有在应用层才能确保功能的完整性和正确性，底层系统提供的功能只能作为性能优化手段，而不能替代应用层的实现。
2025-02-06 20:00:19
701
原创 多主策略记录
当某个节点不可用时，系统会将本应写入该节点的数据暂时存储在其他节点上，并在目标节点恢复后将其转移回去。它通过为每个节点维护一个向量（数组），记录该节点和其他节点的事件顺序，从而解决分布式系统中的并发冲突。：在替代节点上存储数据的同时，记录一个“Hint”，指示数据应最终写入的目标节点。：接收消息时，合并本地向量时钟和接收到的向量时钟，取每个元素的最大值。：当目标节点恢复后，替代节点将数据转移回目标节点，并删除Hint。：每个节点维护一个向量，向量的每个元素对应一个节点的逻辑时钟。
2025-02-05 14:56:43
809
原创 热点账户优化和影子表压测
该方案需结合业务容忍延迟的特性，配套完善的对账机制，是金融级高并发系统的经典设计模式。优势：无锁插入，支持每秒10万+写入（MySQL单机插入约5万/秒，分库分表后可更高）。在高并发交易场景（如红包发放、秒杀活动）中，若直接对核心账户余额进行实时更新（用户请求 → 缓冲账户（高速写入） → 异步合并 → 核心账户（批量更新）：用户实时余额=核心账户余额 + 未合并的缓冲变动（前端展示用）。轻量级记账表，仅记录流水（用户ID、操作类型、金额、状态）。核心账户更新：单次合并处理500用户，整体3万+ TPS。
2025-02-03 19:12:06
695
原创 动态分库分表
在生成用户ID时，通过特定规则（基因）携带业务属性（如地域、业务线），确保关联数据落在同一分片。用户ID = 业务线（2位） + 用户注册时间（4位年月） + 自增序列（10位）。增加分片数量时（如从8个扩容到16个），需对所有数据重新取模，导致全量数据迁移。业务关联数据（如用户与订单）分散在不同分片，难以高效实现JOIN。涉及多分片的查询（如统计全表）需要聚合多个分片结果，性能低下。按基因维度扩容（如新增一个地域分片），仅需迁移该地域数据。计算分片，确保同一业务线、同一时间段的数据在同一分片。
2025-02-03 18:59:05
692
原创 混沌工程记录
验证线性一致性的核心是通过记录操作历史、分析全局顺序，并结合工具自动化检测。对于分布式存储系统，建议使用Jepsen进行故障注入测试，并结合Porcupine或TLA+进行形式化验证，同时设计严格的读写测试用例覆盖边界场景。
2025-02-03 18:37:17
996
原创 LSM对于特殊数据的优化手段
另外，可能需要提到其他现有的改进方案，如FloDB针对写入优化的两层结构，但用户的问题更侧重于不同工作负载的优化，而不是通用的结构设计。每个部分的结构可以统一，先说明该工作负载的特点，然后存在的挑战，再提出优化策略，并举例现有的实现（如LHAM、RocksDB的PlainTable、WiscKey等）。最后是追加为主的数据。首先，用户提到的LHAM是针对时态数据的优化，通过在组件上附加时间戳范围，并调整合并过程，确保时间范围不重叠，这样查询时就能快速定位到相关的组件，避免扫描不必要的数据。
2025-01-26 19:43:07
819
原创 FloDB 设计与思考
另外，考虑GC的问题，原来的堆上数据结构会有大量小对象导致GC压力，而FloDB的哈希表可能设计为更紧凑的结构，或者使用off-heap的内存管理，但这里用户提到的是哈希表在堆上可能的问题，而FloDB可能采用了不同的内存管理方式，比如并发哈希表使用更少的小对象，或者批量迁移减少了对象的频繁创建和销毁，从而减轻了GC负担。总结来说，FloDB的设计通过分层结构，将高频的写入操作由高效的哈希表处理，然后批量迁移到跳跃表，这样既保证了写入的高吞吐，又利用跳跃表的有序性支持范围查询。
2025-01-26 19:36:36
639
原创 IM系统设计
利用last message id作为这个作为最后一个消息体。利用ZSET来维护连接的定时心跳，来续约运营商的连接不断开。读多写少，一般采用写扩散成timeline来做。timeline和批量未读和ack。
2025-01-22 18:54:08
166
原创 数据平滑迁移
如果开启双写后还有延迟，可能导致ub行为！，所以双写后还要观察。全量 binlog的位置需要持久化，后续增量需要接着按这个同步。灰度切流，白名单放行，观察........... 关闭双写。如果业务对不停机的要求不高的话，可以采用停机等待增量。从关闭双写开始，不可回滚，有数据丢失风险！需要继续监控双写写新库的情况，可能还需要回退。最小id和最大id需要并发。同时binlog同步有延迟。
2025-01-21 20:47:32
228
原创 多级缓存以及热点监测
注意local cache的TTL需要大于 redis的TTL， 因为数据一致性的问题，当然这种情况不一定可以保障数据的实时一致性，但是可以保障TTL的最终一致性得到保障。请求先经过nignix或者gateway进行路由转发到无状态的服务器上，然后local cache, 分布式cache， db三层架构，双层缓存。本质上还是缓存穿透问题，boomfilter。事件驱动通知：callback，让用户决定如何处理，限流还是扩容之类的，还是短时间不过期。和传统分布式缓存一样还是还是采用标准的写db， 删缓存。
2025-01-21 01:01:47
509
原创 一文说透分布式事务
多个节点，如何实现ACID，一致性，可用性，性能如何取舍都是挑战。设计需要考虑，事务状态在哪里感知（需做高可用），以及出现故障和分区，是不断像2pc重试还是需要回滚以及回滚方式，以及业务入侵程度。同步与异步，一致性的考虑（任何时间都有可能故障，需要做分类讨论故障情况）
2025-01-05 14:56:56
832
原创 mini-spring源码分析
应用上下文ApplicationContext是spring中较之于BeanFactory更为先进的IOC容器，ApplicationContext除了拥有BeanFactory的所有功能外，还支持特殊类型bean如上一节中的BeanFactoryPostProcessor和BeanPostProcessor的自动识别、资源加载、容器事件和监听器、国际化支持、单例bean自动初始化等。而ApplicationContext面向spring的使用者，应用场合使用ApplicationContext。
2024-11-27 15:27:57
859
1
原创 一种更快的Kmeans原理与实现
如果我们预先计算出了这两个质心之间的距离D(j1,j2)，则如果计算发现2D(x,j1)≤D(j1,j2),就可以知道D(x,j1)≤D(x,j2)。在距离计算方面，每次迭代的最小距离计算次数为k*(k-1)/2，对于较大的k（例如矢量量化），这可能是主要的开销。我们不维护每一对点的距离的上界，只维护一个数据点到它的锚定点的距离的上界u(x)。我们维护每一个数据点x到中点c的距离的下界l(x,c)，一开始赋值为距离，迭代的时候，根据定理2，d)的时间复杂度，其中k是中心点的数量，d是数据的维度。
2024-01-20 15:39:31
896
原创 linux 内存
but 它又不能被杀掉，这就会导致随着它的内存开销变大，OOM killer不停地被唤醒，从而把其他进程一个个给杀掉，我们之前在生产环境中就遇到过类似的案例。系统内存不足时会唤醒OOM killer来选择一个进程给杀掉，在我们这个例子中它杀掉了这个正在内存泄漏的程序，该进程被杀掉后，整个系统也就变得安全了。如果此时系统中有很多进程都在申请内存，那么这些申请内存的进程都会被阻塞在这里，这就形成了一个恶性循环，甚至会引发系统长时间无响应（然后是cat /proc/meminfo。这两个是最开始排查的用的。
2024-01-12 19:48:40
581
原创 linux磁盘总结
linux读写磁盘，如果都是采用directIO的话，效率太低，所以我们在读写磁盘上加了一层缓存，page_cache。读的话，如果page_cache有的话，就不用向磁盘发出请求。写的话，也直接写入的page_cache就行了，异步刷回磁盘（操作系统不crash，不会丢失）。如果查看page_cache的大小：cat /proc/meminfo。
2024-01-11 12:03:58
1076
原创 LLVM入门
LLVM的IR中间层面的抽象很好的解耦了高级语言和机器环境，不想gcc N * M的复杂度。LLVM的IR可以解释执行，同时也可以编译执行。数据库编译查询可以通过两者混用来提高效率。前端生产AST树通过各种优化pass生成DAG,然后通过我们的后端生产汇编代码。同时我们熟知的clang只不过是llvm编译组件的前端。前端要注意有语义分析，这可能就是C++说的语义吧。
2024-01-04 11:52:22
368
原创 网络协议疑点记录
这种算法的基本思路是：当一个路由器启动的时候，首先是发现邻居，向邻居 say hello，邻居都回复。在 BGP 里面，除了下一跳 hop 之外，还包括了自治系统 AS 的路径，从而可以避免坏消息传得慢的问题，也即上面所描述的，B 知道 C 原来能够到达 A，是因为通过自己，一旦自己都到达不了 A 了，就不用假设 C 还能到达 A 了。eBGP 和 iBGP。距离矢量路由算法,bellman-ford算法，每个路由节点知道全局的路由信息，通过和邻居交换信息得到，然后一个问题就是好消息传的快，坏消息传的慢，
2023-12-10 19:59:40
1252
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人