- 博客(174)
- 收藏
- 关注
RSS订阅原创 KubeFlow
Kubeflow = Kubernetes 原生的全链路 ML 平台，通过 PIPELINE + JOB + HPO + SERVING 覆盖所有 ML 生命周期，做到可复现、可扩展、可自动化。如果你需要，我还能为你生成：📌《Kubeflow 入门到精通》学习路线图（分 7 天）📌 企业级 Kubeflow 架构蓝图📌 KFP Pipeline 示例（含代码）📌 TFJob/PyTorchJob 模板📌 生产落地最佳实践（可直接用于团队文档）需要哪一个？
2025-11-17 23:15:21
790
原创 任务计算和计算图优化
计算图系统是现代AI基础设施的核心，它不仅仅是执行数学计算的工具，更是连接算法创新与硬件效率的关键桥梁。优秀的设计需要在表达力、性能、易用性之间找到精巧的平衡，同时保持系统的可扩展性和演进能力。随着AI技术的不断发展，计算图系统将继续演化，吸收更多编译技术、系统优化和自动化方法，为下一代AI应用提供更强大、更高效的基础设施支撑。print("PyTorch计算图使用示例")# 设置随机种子以便复现结果print("\n1. 基础计算图示例")# 创建需要梯度的张量（叶子节点）
2025-11-01 17:04:59
514
原创 大数据模糊计算
模糊计算技术，也称为近似计算或概率计算，是一种在计算过程中通过引入可接受误差，以简化计算过程、提升计算效率的数值计算方法。与传统的精确计算不同，模糊计算的核心思想是在保证计算结果满足一定精度要求的前提下，通过牺牲部分精确性来换取计算效率的大幅提升。这种思想的产生源于对实际应用需求的深刻理解。在许多实际场景中，我们并不需要绝对精确的计算结果，只要结果在可接受的误差范围内，就能够满足业务决策的需要。
2025-10-08 18:46:44
529
原创 数据湖架构
Apache Paimon 是一个流数据湖平台，于 2024 年 4 月 16 日正式成为 Apache 顶级项目。Paimon 创新地结合了湖格式和 LSM（日志结构合并树）结构，将实时流更新引入湖架构。Paimon 的核心特性包括：实时更新能力，主键表支持大规模数据的实时流更新，可在 1 分钟内完成实时查询；灵活的更新机制，通过定义合并引擎，用户可以选择去重保留最后一行、部分更新、聚合记录或第一行更新等多种策略；变更跟踪更新，定义变更日志生成器，为合并引擎生成正确完整的变更日志；
2025-10-08 16:00:43
1405
原创 产品思维杂谈
产品用户的整体的体验，不只是app，比如美团，配送服务，店家菜好不好吃，打车，车是不是舒服 的。6.需求有时空，场景性，人是需求的集合。上门理发的失败，套装，理发服务纠纷如何做，打车费用，培训成本，管理成本，入驻成本。内容社区，社交媒体，头部大v，内容生产生态才是真的重点，决定了内容社区的边界。美甲师如何进入平台，平台如何管理，如何处理客诉，培训流程。即时性的需求出现，如何撮合多方需求，服务的标准化非常难。人的时间是不变的，你多的时间，就是别人少的时间。5.需求有不同的重要程度，必要性，期待性，惊喜性。
2025-08-23 15:10:59
210
原创 记录一下一种神奇的GC优化机制
Go Ballast 本质是“欺骗”GC 机制：用虚拟内存抬高 GC 触发门槛，减少无效回收频次，同时避免自身引发额外开销。这种设计以极小代价（虚拟地址空间）换取 GC 行为的确定性，尤其适用于内存波动大的服务启动阶段12。
2025-08-03 13:58:16
564
原创 Abase和ByteKV存储方案对比
Abase 和 ByteKV 是字节跳动内部自研的两款分布式 KV 存储系统，虽然都服务于大规模在线业务，但在设计目标、架构模型、适用场景等方面存在显著差异。
2025-07-04 20:47:18
392
原创 支付系统简单设计
状态机跳变：fail后，callback成功 1.fail前查，如果还在process不变更状态 2.引入监控打点，人工处理。异常流程:超时处理（1.超时时间 2.间隔时间（随机+倍增），死信队列），callBack接口，主动查询。实体：用户表，商家表，订单表，支付表，审计表。幂等处理：幂等键，全球最终一致性幂等方案。前端 -----支付系统---第三方服务。流数据库（回放对账），时序金融数据选型。2.用例：支付，扣款，付款，通知，对账。1.角色：用户，商家，第三方支付机构。3.生命周期：账单流转状态。
2025-07-04 11:28:39
254
原创 Apache Pulsar 消息、流、存储的融合
消息队列在大层面有两种不同类型的应用，一种是在线系统的message queue，一种是流计算，data pipeline的streaming高throughout，一致性较低，延迟较差的过程。存算分离 扩容和缩容快速segment 打散（时间和容量切分）多机器能力多租户的能力，配额原来的架构，多种消息中间件不同场景不同选型统一兼容旧系统协议，统一存储bookkeeper内部二级分层存储，统一批存储和流存储（之前外部系统计算存储到HDFS）
2025-05-14 17:33:38
491
原创 从Aurora 架构看数据库计算存储分离架构
单就公有云来说，现在云数据面临的挑战有以下 5 个：跨 AZ 的可用性与数据安全性。现在都提多 AZ 部署，亚马逊在全球有 40 多个 AZ， 16 个 Region，基本上每一个 Region 之内的那些关键服务都是跨 3 个 AZ。你要考虑整个 AZ 意外宕机或者计划内维护要怎么处理，数据迁移恢复速度怎么样。以传统的 MySQL 为例，比如说一个机器坏了，可能这个机器上存了几十 T、上百 T 的数据，那么即使在万兆网卡的情况下，也要拷个几分钟或者几十分钟都有可能。那么有没有可能加快这个速度。
2025-05-13 12:38:01
948
原创 广告事件聚合系统设计
规模上 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
1008
原创 云盘系统设计
冷数据归档是优化存储成本、提升数据库性能的关键技术手段，其实践需结合业务场景和技术方案综合设计。冷数据归档是优化存储成本、提升数据库性能的关键技术手段，其实践需结合业务场景和技术方案综合设计。本质差异协议本质：长轮询是 HTTP 的变种，WebSocket 是独立协议，SSE 是 HTTP 流37。核心差异：通信方向（单向/双向）、实时性、资源开销35。选型原则：根据实时性需求、技术栈兼容性、服务器资源综合决策57。3.md5在判断什么完整性MD5在文件分片传输场景中用于验证。
2025-05-02 20:22:30
1035
原创 Go与Cpp的本质区别
维度Go 语言特性C++ 语言特性内存管理自动垃圾回收手动管理或智能指针并发模型Goroutines + Channels（轻量级）线程 + 锁（重量级）语法复杂度简洁、强约束复杂、高灵活性编译速度快速较慢（尤其大型项目）运行时性能适合高并发 I/O适合计算密集型任务应用领域Web 后端、云原生系统编程、游戏引擎、嵌入式通过上述对比，可依据项目需求（性能、开发效率、安全性等）在两者间做出选择但是造成这个不同问题背后的原因是什么？
2025-04-30 11:00:47
1407
原创 全局id生成器生产方案
中心式的解决方案实现简单，但是跨区域的性能损耗大，因此实际部署时，会将 PD 集群部署在同一个区域，避免跨区域的性能损耗。PD 的 TSO 授时工作是由集群中 leader 来完成的。此外，PD 通过引入 etcd 解决了单点的可用性问题，一旦 leader 节点故障，会立刻选举新的 leader 继续提供服务，理论上来讲由于 TSO 授时只通过 PD 的一个 leader 提供，所以可能是一个潜在的瓶颈，但是从目前使用情况看，PD 的 TSO 分配性能并没有成为过 TiDB 事务中的瓶颈。
2025-04-29 20:51:27
879
原创 Spark知识总结
宽窄依赖：父RDD的分区只对应下面子RDD的一个分区，为窄依赖。如果被传到多个子RDD分区，就需要。父RDD的一个分区会被传到几个子RDD分区。如果被传到一个子RDD分区，就可以。
2025-04-28 20:22:48
509
原创 ClickHouse 设计与细节
ClickHouse 是一款备受欢迎的开源列式在线分析处理 (OLAP) 数据库管理系统，专为在海量数据集上实现高性能实时分析而设计，并具备极高的数据摄取速率 1。其在各种行业中得到了广泛应用，包括众多知名企业，例如超过半数的财富全球 2000 强公司都信赖 ClickHouse 来处理其生产工作负载 1。值得注意的是，在 2024 年，ClickHouse 的设计与架构以一篇名为 “ClickHouse - Lightning Fast Analytics for Everyone” 的论文形式发表于国际
2025-04-22 16:35:52
1140
原创 实时直播弹幕系统设计
整个服务读多写少，读写比例大概几百比1.如果实时性要求高的话，可以采用长连接模式（轮询的话，时效性不好，同时对于评论少的直播间可能空转）websocket 和 SSE架构只要求服务端推送的话，可以选SSE，评论还是少量的，减少资源的浪费长连接选型单体架构发布订阅模式去推送消息到SSE,会导致无用的消息，浪费大量SSE资源按直播间分区，然后消费，可以缓解问题，但没有解决问题多个topic 动态 直播间。对元数据服务比如zookeeper的压力？
2025-04-18 20:06:52
1095
原创 大数据调度组件
分离资源管理（RM）与应用逻辑（AM），支持多计算框架（如MapReduce、Spark）。预分队列资源（如A队列80%、B队列20%），允许弹性抢占（如B队列白天可占100%）。2. 资源利用率高：动态分配减少空闲 2. 资源模型较简单（仅CPU/内存）。容器配置：优化Container内存/CPU分配，避免OOM或资源碎片。统一资源池化管理，通过动态分配提升利用率（如空闲资源跨队列借用）。调度器参数：调整容量调度器的最大资源占比、最小资源保障。
2025-04-17 20:42:39
454
原创 交易中台代码解析（TODO）
完整的微服务架构，集成了SpringCloud、Eureka、Feign等组件。- 采用领域驱动设计(DDD)思想，清晰划分了购买域、履约域、售后域和结算域。这个项目对于想要学习企业级应用架构设计和实现的人来说，是一个很好的参考案例。- 实现了业务能力和领域能力的分离，提高了系统的可维护性和扩展性。- 多数据源和分库分表支持，使用Sharding-sphere。- 分布式锁、分布式ID、重试机制等基础组件的抽象和实现。- 分布式重试机制：支持自动重试和延迟队列重试。- 通过扩展点引擎支持业务差异化。
2025-04-15 22:10:54
175
原创 大厂文章阅读
1.1)任务失败如何处理(CAS失败也可用)：1.指数退避,匹配下游任务执行系统的处理能力。比如收到下游任务执行系统的流控错误，或者感知到任务执行成为瓶颈，需要指数退避重试。不能因为重试反而加大了下游系统的压力，压垮下游。反压控制，或者类似于flink基于credit 双向同步 的流空机制2.重试的策略要简单清晰，易于用户理解和配置。首先要对错误进行分类，区分不可重试错误，可重试错误，流控错误。不可重试错误是指确定性失败的错误，重试没有意义，比如参数错误，权限问题等等。
2025-04-11 21:07:17
757
原创 如何设计好一张表
最终目标是通过这些“微小”的字段，构建出健壮、可观测、易维护的数据资产体系。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
452
原创 杂记。。。
CRDT通过数学严谨的数据结构设计，为分布式系统提供了去中心化高可用的解决方案，但其落地需权衡内存开销、时钟一致性和业务操作约束。在Redis等数据库场景中，需结合具体命令特性选择CRDT类型，并设计配套的冲突解决与垃圾回收机制多租户实现需根据场景平衡隔离粒度与资源成本轻量级场景可采用字段隔离或单库多租户12；高要求场景建议物理隔离或Kubernetes CRD管理34。QoS设计需聚焦资源公平性与SLA保障，通过动态策略提升系统弹性4。
2025-02-27 16:38:02
1007
原创 各种协议设计
这篇论文《End-to-End Arguments in System Design》由J.H. Saltzer、D.P. Reed和D.D. Clark撰写，首次发表于1981年，是计算机系统设计领域的经典文献之一。端到端原则是系统设计中的一种“奥卡姆剃刀”原则，它指导设计者将功能放置在最适合的层次（通常是应用层）。因此，通信子系统的可靠性功能只能减少应用层的重传次数，而不能替代应用层的功能。：只有在应用层才能确保功能的完整性和正确性，底层系统提供的功能只能作为性能优化手段，而不能替代应用层的实现。
2025-02-06 20:00:19
789
原创 多主策略记录
当某个节点不可用时，系统会将本应写入该节点的数据暂时存储在其他节点上，并在目标节点恢复后将其转移回去。它通过为每个节点维护一个向量（数组），记录该节点和其他节点的事件顺序，从而解决分布式系统中的并发冲突。：在替代节点上存储数据的同时，记录一个“Hint”，指示数据应最终写入的目标节点。：接收消息时，合并本地向量时钟和接收到的向量时钟，取每个元素的最大值。：当目标节点恢复后，替代节点将数据转移回目标节点，并删除Hint。：每个节点维护一个向量，向量的每个元素对应一个节点的逻辑时钟。
2025-02-05 14:56:43
856
原创 热点账户优化和影子表压测
该方案需结合业务容忍延迟的特性，配套完善的对账机制，是金融级高并发系统的经典设计模式。优势：无锁插入，支持每秒10万+写入（MySQL单机插入约5万/秒，分库分表后可更高）。在高并发交易场景（如红包发放、秒杀活动）中，若直接对核心账户余额进行实时更新（用户请求 → 缓冲账户（高速写入） → 异步合并 → 核心账户（批量更新）：用户实时余额=核心账户余额 + 未合并的缓冲变动（前端展示用）。轻量级记账表，仅记录流水（用户ID、操作类型、金额、状态）。核心账户更新：单次合并处理500用户，整体3万+ TPS。
2025-02-03 19:12:06
878
原创 动态分库分表
在生成用户ID时，通过特定规则（基因）携带业务属性（如地域、业务线），确保关联数据落在同一分片。用户ID = 业务线（2位） + 用户注册时间（4位年月） + 自增序列（10位）。增加分片数量时（如从8个扩容到16个），需对所有数据重新取模，导致全量数据迁移。业务关联数据（如用户与订单）分散在不同分片，难以高效实现JOIN。涉及多分片的查询（如统计全表）需要聚合多个分片结果，性能低下。按基因维度扩容（如新增一个地域分片），仅需迁移该地域数据。计算分片，确保同一业务线、同一时间段的数据在同一分片。
2025-02-03 18:59:05
817
原创 混沌工程记录
验证线性一致性的核心是通过记录操作历史、分析全局顺序，并结合工具自动化检测。对于分布式存储系统，建议使用Jepsen进行故障注入测试，并结合Porcupine或TLA+进行形式化验证，同时设计严格的读写测试用例覆盖边界场景。
2025-02-03 18:37:17
1089
原创 LSM对于特殊数据的优化手段
另外，可能需要提到其他现有的改进方案，如FloDB针对写入优化的两层结构，但用户的问题更侧重于不同工作负载的优化，而不是通用的结构设计。每个部分的结构可以统一，先说明该工作负载的特点，然后存在的挑战，再提出优化策略，并举例现有的实现（如LHAM、RocksDB的PlainTable、WiscKey等）。最后是追加为主的数据。首先，用户提到的LHAM是针对时态数据的优化，通过在组件上附加时间戳范围，并调整合并过程，确保时间范围不重叠，这样查询时就能快速定位到相关的组件，避免扫描不必要的数据。
2025-01-26 19:43:07
866
原创 FloDB 设计与思考
另外，考虑GC的问题，原来的堆上数据结构会有大量小对象导致GC压力，而FloDB的哈希表可能设计为更紧凑的结构，或者使用off-heap的内存管理，但这里用户提到的是哈希表在堆上可能的问题，而FloDB可能采用了不同的内存管理方式，比如并发哈希表使用更少的小对象，或者批量迁移减少了对象的频繁创建和销毁，从而减轻了GC负担。总结来说，FloDB的设计通过分层结构，将高频的写入操作由高效的哈希表处理，然后批量迁移到跳跃表，这样既保证了写入的高吞吐，又利用跳跃表的有序性支持范围查询。
2025-01-26 19:36:36
676
原创 数据平滑迁移
如果开启双写后还有延迟，可能导致ub行为！，所以双写后还要观察。全量 binlog的位置需要持久化，后续增量需要接着按这个同步。灰度切流，白名单放行，观察........... 关闭双写。如果业务对不停机的要求不高的话，可以采用停机等待增量。从关闭双写开始，不可回滚，有数据丢失风险！需要继续监控双写写新库的情况，可能还需要回退。最小id和最大id需要并发。同时binlog同步有延迟。
2025-01-21 20:47:32
269
原创 多级缓存以及热点监测
注意local cache的TTL需要大于 redis的TTL， 因为数据一致性的问题，当然这种情况不一定可以保障数据的实时一致性，但是可以保障TTL的最终一致性得到保障。请求先经过nignix或者gateway进行路由转发到无状态的服务器上，然后local cache, 分布式cache， db三层架构，双层缓存。本质上还是缓存穿透问题，boomfilter。事件驱动通知：callback，让用户决定如何处理，限流还是扩容之类的，还是短时间不过期。和传统分布式缓存一样还是还是采用标准的写db， 删缓存。
2025-01-21 01:01:47
560
原创 一文说透分布式事务
多个节点，如何实现ACID，一致性，可用性，性能如何取舍都是挑战。设计需要考虑，事务状态在哪里感知（需做高可用），以及出现故障和分区，是不断像2pc重试还是需要回滚以及回滚方式，以及业务入侵程度。同步与异步，一致性的考虑（任何时间都有可能故障，需要做分类讨论故障情况）
2025-01-05 14:56:56
958
原创 mini-spring源码分析
应用上下文ApplicationContext是spring中较之于BeanFactory更为先进的IOC容器，ApplicationContext除了拥有BeanFactory的所有功能外，还支持特殊类型bean如上一节中的BeanFactoryPostProcessor和BeanPostProcessor的自动识别、资源加载、容器事件和监听器、国际化支持、单例bean自动初始化等。而ApplicationContext面向spring的使用者，应用场合使用ApplicationContext。
2024-11-27 15:27:57
896
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
955
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人