- 综合排序
- 最热优先
- 最新优先
《3D端游云原生协作任务数据一致性优化实战》
团队开发的古风开放世界3D端游，核心玩法“长安工坊”以“多人共建传统木构建筑”为特色，4-6名玩家需分工完成松木收集（用于搭建屋梁）、铁器锻造（制作固定构件）、梁架组装（需3人同步对齐榫卯）三大环节，最终解锁 （分40个测试队伍）中，30%的队伍遭遇严重数据不同步：A玩家提交2块松木后，个人界面显示工坊库存从5增至7，同队B玩家的库存却仍停留在5；更影响体验的是，6支完成搭建的队伍中，2支出现“奖励分化”—3名玩家收到 1000铜钱+木质桌椅装扮，其余玩家却提示“梁架未达稳固标准，任务未完成”，甚至有1名玩家因数据异常重复领取3次奖励。 首先是数据一致性监控：中台每5分钟自动向所有相关容器发送“数据校验指令”，对比容器本地缓存与中台数据源的差异（如松木库存、进度值等核心字段），若差异率超过0.1%（如100个容器中有1个数据偏差），则自动触发缓存重置 这段优化经历让我们沉淀出3D端游云原生协作任务的核心开发思路：多人协作场景的技术挑战，本质是“分布式部署的灵活性”与“数据一致性的刚性需求”之间的平衡艺术，而非单纯的技术栈选择问题。
21610编辑于 2025-10-22- 来自专栏编程一生
数据一致性-对账
强一致性的协议和手段主要有：二阶段提交(2PC)、三阶段提交(3PC)、TCC(Try-Confirm-Cancel)补偿型。这里面经常有人把两阶段提交和TCC补偿型混淆。
2.1K21发布于 2019-10-25 - 来自专栏咖啡拿铁
谈谈数据一致性
什么是数据一致性 数据一致性这个单词在平常开发中，或者各种文章中都能经常看见，我们常常听见什么东西数据不一致了，造成了一定的损失，赶快修复一下。 一般来说数据一致性我们可以分成三类，时间点一致性，事务一致性，应用一致性。 在《DDIA》这本书中描述了下面3个作用: 加锁与主节点选举:主从复制系统需要确保只有一个主节点，否则会产生脑裂。选举新的主节点一般是使用锁:每个启动的节点都需要获得锁。 举个简单的例子如果节点1更新了数据A，节点2读取数据A，并更新数据B，这里的数据B有可能是根据数据A计算出来的，所有具备因果关系，但是如果节点3看到的是先更新的B，再更新的A那么就破坏了因果一致性。 Operational Characterization of Weak Memory Consistency Models:https://mp.weixin.qq.com/s/gg4q_53eiHCI3OUWzN7eWg
3.3K40发布于 2019-10-13 - 来自专栏java一日一条
浅析数据一致性
这3个核心的需求是：Consistency，Availability和Partition Tolerance，赋予了该理论另外一个名字 － CAP。 CAP定理认为，一个提供数据服务的存储系统无法同事满足数据一致性、数据可用性、分区容忍性。 例如：N=3，W=2，R=2，那么表示系统中数据有3个不同的副本，当进行写操作时，需要等待至少有2个副本完成了该写操作系统才会返回执行成功的状态，对于读操作，系统有同样的特性。 3. 当R=Q,W=Q(Q=N/2+1)时，系统在读写性能之间取得平衡，兼顾了性能和可用性。 3. 采用乐观锁原理实现的同步 我们举个例子说明该算法的实现原理。
2.1K11发布于 2018-09-18 - 来自专栏木东居士的专栏
浅谈数据一致性
浅谈数据一致性 |0x00 数据不一致产生的原因 互联网的工程开发，与传统软件相比，往往要面临非常复杂多变的业务场景，这是老生常谈的问题了。 步骤1是为了将数据传递给财务系统，步骤2是为了重新调整检索顺序，步骤3是为了一些事实的推荐场景应用。 |0x02 解决数据一致性的模式 通过上一阶段理论演进的阐述，可以看出，互联网工程领域往往通过“最终一致性”的方式，来保障数据的一致性。因此接下来提到的解决思路，都是围绕“最终一致性”展开的。 |0xFF 从全局角度再思考 不论是从数据库层面，还是从工程层面，或者是人工兜底层面，数据一致性总有解决的方法，区别只是场景适用性与成本高低的问题。 随着技术发展的越来越快，解决方案手段的不断增加，技术架构解耦就是一种必然的要求，在不同的场景下选用自己最适合的方案，但由此带来的数据一致性问题也将成为技术融合道路上的一个阻碍。
1.4K30发布于 2020-11-03 - 来自专栏开源部署
Hadoop HDFS 数据一致性
HDFS 会对写入的所有数据计算校验和(checksum)，并在读取数据时验证校验和。针对指定字节的数目计算校验和。字节数默认是512 字节，可以通过io.bytes.per.checksum属性设置。通过CRC-32编码后为4字节。
60310编辑于 2022-06-28 - 来自专栏喵叔's 专栏
微服务--数据一致性
本篇文章讲解微服务数据一致性相关的知识 一、案例 在使用微服务时，存在跨多个服务更新数据库数据的情况。 那么这就会出现一个问题，比如我们有三个服务（如下图），正常情况下，当一个请求进来时，服务1到服务3会分别改变其数据库中存储的数据，但是如果出现部分服务网络不通或者部分服务失效的情况，那么整个服务调用链就会失效 在我们实际项目中只要涉及数据一致性的问题，就可以分为两种情况： 可实时数据不一致，但最终数据必须一致（最终一致性） 实时数据必须一致 针对这两种情况我们分别来看一下如何解决。 2失败 同步骤5 10 服务3修改数据库失败 同步骤6 11 服务3将消息2标记为已消费失败 同步骤8 上面的解决方案看似完美，其实存在两个问题： 方案利用了MQ的重试机制，因此在步骤6和步骤10重复执行的情况下 小结 解决数据一致性，就是这么简单。
69620编辑于 2022-09-28 - 来自专栏散尽浮华
mysql主从同步(3)-percona-toolkit工具（数据一致性监测、延迟监控）使用梳理
mysql replication，mysql在复制方面还是会有一些常规问题，比如主库宕机或者从库宕机有可能会导致复制中断，通常需要进行人为修复，或者很多时候需要把一个从库提升为主库，但对从库和主库的数据一致性不能保证一样 比如说，线上数据库做了主从同步环境，数据库在进行了迁移后，需要对mysql迁移（Replication）后的数据一致性进行校验，但又不能对生产环境使用造成影响，pt-table-checksum成为了绝佳也是唯一的检查工具 percona-toolkit工具中最主要的三个组件分别是： 1）pt-table-checksum 负责监测mysql主从数据一致性 2）pt-table-sync 负责当主从数据不一致时修复数据 SLAVE ON *.* TO 'root'@'192.168.1.101' IDENTIFIED BY '123456'; mysql> flush privileges; 如下，在主库上执行的一个检查主从数据一致性的命令 root,p=123456 --execute else echo "data is ok" fi [root@master-server ~]# crontab -l #检查主从huanqiu库数据一致性
3.7K101发布于 2018-01-22 - 来自专栏有文化的技术人
Mongo数据一致性浅析
cmgo-9t1zzciv_0:PRIMARY> db.oplog.rs.find({}).limit(1).pretty() { "ts" : Timestamp(1672717376, 3) "v" : 2, "op" : "u", "ns" : "component.deploy", "ui" : UUID("a164a9ab-7b3a
77120编辑于 2023-08-19 - 来自专栏Michael阿明学习之路
ZooKeeper 保证数据一致性
分布式一致性原理 CAP 原理认为，一个提供数据服务的分布式系统 无法同时满足 数据一致性（Consistency）、可用性（Availibility）、分区耐受性（Patition Tolerance 架构 收到请求后，发送给其他服务器进行表决 如果收到多个，就按时间戳和服务器排序规则进行表决 只有收到多数表决同意时，才会决定执行 表决机制保证只有一个请求会执行，保证一致性 牺牲了部分可用性，换来数据一致性
42420发布于 2021-09-06 - 来自专栏架构狂人
redis 如何保证数据一致性
为什么会数据不一致 数据一致性：指的是redis缓存跟数据库的数据的一致。假如缓存中没有数据，那么数据库的值必须是最新的。如果缓存中有数据，那么缓存中的值需要跟数据库的值相同。 理解完上述数据一致性的前提，我们看下什么情况下会导致缓存跟数据库的数据不一致。
1.3K20编辑于 2023-08-16 - 来自专栏菜鸟成长学习笔记
Redis缓存数据一致性分析
文章主旨 文章前面提到的数据一致性，指的是MySQL与缓存中数据如何保持同步。后面文章也是针对如何去实现数据同步进行分析。 更新策略 先缓存后数据库 [redis-desing-3.png] 策略说明 后端发生更新请求，更新对应的Redis缓存。在这个过程中可以直接删除，在新写入；也可以采用更新的方式。
83831发布于 2021-02-02 - 来自专栏Java技术债务
ClickHouse的数据一致性（七）
目录 数据一致性的方案 1 手动使用OPTIMIZE（强烈不建议生产上使用） 2 通过 Group by 去重 3 通过 FINAL 查询 数据一致性的方案 查询 CK 手册发现，即便对数据一致性支持最好的 Mergetree，也只是保证最终一致性: 1手动使用OPTIMIZE 2 通过 Group by 去重 3 通过 FINAL 查询 我们在使用 ReplacingMergeTree、SummingMergeTree 3 通过 FINAL 查询 在查询语句后增加 FINAL 修饰符，这样在查询的过程中将会执行 Merge 的特殊逻辑(例 如数据去重，预聚合等)。
75020编辑于 2022-08-09 mysql和redis数据一致性
删除缓存 activate B B->>Cache: 3. 读缓存（未命中） B->>DB: 4. 查询新数据 DB-->>B: 返回新数据 B->>Cache: 5. 3. 避免缓存穿透直接删除缓存可能引发大量数据库查询（缓存穿透）。5秒限制：在缓存失效期间，其他线程直接读取数据库，减少数据库压力。4. 更新数据库 userRepository.save(user); // 3. 3. 延时删除缓存通过Redis的过期机制实现延时删除，避免直接删除导致的冲突。 redis逻辑清晰，可控性强代码侵入性大，可能出现数据不一致适用于高并发读写场景Binlog 监听同步解析 MySQL Binlog 并同步到 Redis（如 Canal）自动化同步，降低应用层负担存在延迟，数据一致性需优化高吞吐量业务
26900编辑于 2025-03-16- 来自专栏Java技术债务
redis缓存如何保证数据一致性
问题的引入 同时有请求A和请求B进行更新操作，那么会出现 （1）线程A更新了数据库 （2）线程B更新了数据库 （3）线程B更新了缓存 （4）线程A更新了缓存 如果访问数据库后，不更新缓存，直接删除缓存 假设这会有两个请求，一个请求A做查询操作，一个请求B做更新操作，那么会有如下情形产生 （1）缓存刚好失效 （2）请求A查询数据库，得一个旧值 （3）请求B将新值写入数据库 （4）请求B删除缓存 （5）请求 发生上述情况有一个先天性条件，就是步骤（3）的写数据库操作比步骤（2）的读数据库操作耗时更短，才有可能使得步骤（4）先于步骤（5）。 可是，大家想想，数据库的读操作的速度远快于写操作的（不然做读写分离干嘛，做读写分离的意义就是因为读操作比较快，耗资源少），因此步骤（3）耗时比步骤（2）更短，这一情形很难出现。 （1）先淘汰缓存 （2）再写数据库（这两步和原来一样） （3）休眠1秒，再次淘汰缓存 这么做，可以将1秒内所造成的缓存脏数据，再次删除。 问题：如果你用了mysql的读写分离架构怎么办？
93230编辑于 2022-08-09 - 来自专栏技术杂记
Mysql复制数据一致性检查1
replication-check-vm,u=root --ask-pass Enter MySQL password: Checksumming user_key_db.log_records: 3%
36410编辑于 2022-04-23 - 来自专栏技术杂记
Mysql复制数据一致性检查
percona 收集整理和维护而成 其中有两个特别有用的工具 pt-table-checksum 和 pt-table-sync ，分别可以用来进行主从一致性检查，和不一致数据修复 下面分享一下Mysql复制数据一致性检查的基本操作 [root@replication-check-vm src]# wget http://www.percona.com/downloads/percona-release/redhat/0.1-3/ /redhat/0.1-3/percona-release-0.1-3.noarch.rpm Resolving www.percona.com... 74.121.199.234 Connecting /percona-release/redhat/0.1-3/percona-release-0.1-3.noarch.rpm Connecting to www.percona.com|74.121.199.234 -K/s in 0.002s 2015-11-19 21:21:09 (4.12 MB/s) - `percona-release-0.1-3.noarch.rpm' saved [6566/
41810编辑于 2022-04-23 - 来自专栏蓝天
向量时钟解决数据一致性
向量时钟解决数据一致性 向量时钟简介 向量时钟，最早是用于分布式系统中进程间的时间同步。由于在分布式系统中没有一个直接的全局逻辑时钟。 数据一致性（Quorum） 定义 N：系统中数据的备份数 R：读取操作最小成功数 W：写操作最小成功数 要求：R+W>N 配置 R+W>N，保证读操作至少能读取到一个最新数据 读写速度受性能最差的节点影响 R和W越小，系统的响应越快 W越大，数据的一致性，可用性越强 通常：N=3， R=W=2 时钟向量与数据冲突处理 *将上述向量时钟应用到解决数据一致性的问题上来
94410发布于 2018-08-07 - 来自专栏高剑林的专栏
数据一致性和 io 类型
而在ext3文件系统，fsync和fdatasync是完全一样的。不管是否轻微变化，都要回写inode。 总结 对于单一的存储系统来说，数据一致性，性能和可靠性是几个矛盾的指标。标准的linux内核在这方面也有些左右为难。比如内核在io失败的情况下，一般会重试（内核设置了5次的重试）。
4.1K10发布于 2016-09-26 - 来自专栏大数据架构
Spark CommitCoordinator 保证数据一致性
5.4.4 概述 Spark 输出数据到 HDFS 时，需要解决如下问题： 由于多个 Task 同时写数据到 HDFS，如何保证要么所有 Task 写的所有文件要么同时对外可见，要么同时对外不可见，即保证数据一致性 recoverTask 上文所述的 commitTask 与 commitJob 机制，保证了一次 Application Attemp 中不同 Task 的不同 Attemp 在 commit 时的数据一致性 也即 V2 更易发生数据一致性问题
1.6K41发布于 2018-10-10
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号