数据库一致性

本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 事务的ACID特性 原子性 一致性 隔离性 持久性 消息事务+最终一致性 CC提供了一个编程框架，将整个业务逻辑分为三块：Try、Confirm和Cancel三个操作。以在线下单为例，Try阶段会去扣库存，Confirm阶段则是去更新订单状态，如果更新订单失败，则进入Cancel阶段，会去恢复库存。总之，TCC就是通过代码人为实现了两阶段提交，不同的业务场景所写的代码都不一样，复杂度也不一样，因此，这种模式并不能很好地被复用。 来源： https://www.cnblogs.com/Yanss/p/11676223.html

作者：陈肃 整理：周奇，Apache Flink 社区志愿者 本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎

说在前面 我曾不止一次听说过这句话： “十个女人无法在一个月内生出孩子” 我明白这句话的意思，用来形容我们的开发工作需要循序渐进，没有办法简单的增加人员就能加快研发速度。 这句话也经常被用于反驳产品经理或者老板，试图让他们明白我们内心所表达的观点，老实说我也说过这样的话，当时还觉得挺有道理，现在想来可能有些一厢情愿了。 没错，在现实世界中，当然不可能在一个月内生出孩子，但我们毕竟是做产品写代码的，而不是真的要去生孩子，所以这种说法未免有点偷换概念。 我并不是较真，如果只是想让产品经理明白我们所要表达的观点，我们完全可以用其他的比喻，如实反馈存在的困难与问题即可。 言归正传，这句话与本文有什么关系呢？本文想要就“并发”所带来的问题进行探讨，相信看完后你会对此有一个感觉。 与我之前写的几篇文章一样，并发一词在本文中所表达的意思是： “在分布式环境下，超过一个线程同时对同一个状态进行访问和变更所导致的一致性问题和可用性问题” 问题的根源：状态 我无法给出一个百分比数据用以说明到底有多少后端应用程序在使用数据库，但我想国内涉及到增删查改之类的各种“管理系统”应该不在少数。 说到底，增删改查是落地，而怎么落地则取决于业务的需要，也就是说，业务规则以及流程表达了我们的逻辑，但终究离不开柴米油盐（增删改查）。 那么什么是状态？ 它可以是文件，也可以是数据库，可以是一个变量，也可以是缓存

目录 一、简介 二、基本模型 BSON 数据类型 分布式ID 三、操作语法 四、索引 索引特性 索引分类 索引评估、调优 五、集群 分片机制 副本集 六、事务与一致性 一致性 小结 一、简介 MongoDB 是一款流行的开源文档型数据库，从它的命名来看，确实是有一定野心的。 MongoDB 的原名一开始 来自于 英文单词"Humongous", 中文含义是指"庞大" ，即命名者的意图是可以处理大规模的数据。 但笔者更喜欢称呼它为 "芒果"数据库，除了译音更加相近之外，原因还来自于这几年使用 MongoDB 的两层感觉： 第一层感受是"爽"，使用这个文档数据库的特点是几乎不受什么限制，一方面Json文档式的结构更容易理解，而无Schema约束也让DDL管理更加简单，一切都可以很快速的进行。 第二层感受是"酸爽"，这点相信干运维或是支撑性工作的兄弟感受会比较深刻，MongoDB 由于入门体验"太过于友好"，导致一些团队认为用好这个数据库是个很简单的事情，所以开发兄弟在存量系统上埋一些坑也是正常的事情。 所谓交付一时爽，维护火葬场.. 当然了，这句话可能有些过。 但这里的潜台词是：与传统的RDBMS数据库一样，MongoDB 在使用上也需要认真的考量和看护，不然的化，会遇到更多的坑。 那么，尽管文档数据库在选型上会让一些团队望而却步，仍然不阻碍该数据库所获得的一些支持，比如 DB

CAP CAP是一个已经经过证实的理论：一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。 一致性 我们知道ACID中事务的一致性是指事务的执行不能破坏数据库数据的完整性和一致性，一个事务在执行前后，数据库都必须处于一致性状态。也就是说，事务的执行结果必须是使数据库从一个一致性状态转变到另一个一致性状态。 和ACID中的一致性不同，分布式环境中的一致性是指数据在多个副本之间是否能够保持一致的特性。 分布式系统中，数据一般会存在不同节点的副本中，如果对第一个节点的数据成功进行了更新操作，而第二个节点上的数据却没有得到相应更新，这时候读取第二个节点的数据依然是更新前的数据，即脏数据，这就是分布式系统数据不一致的情况。 在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都能读取到最新的值，那么这样的系统就被认为具有强一致性（或严格的一致性）。 可用性 可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果，如果超过了这个时间范围，那么系统就被认为是不可用的。 “有限的时间内”是在系统的运行指标，不同系统会有差别。例如搜索引擎通常在0.5秒内需要给出用户检索结果。 “返回结果”是可用性的另一个重要指标

一、概述： 　　1、NoSQL数据库（非关系型数据库） 　　2、文档存储 　　3、格式类似JSON，BSON 　　4、最终一致性（非ACID） ， CAP定理（C 一致性，A 高可用，P 分区性） 　　5、高可扩展性（分片） 二、适用场景： 　　数据量大，无事务，非关系型，低价值的数据。 三、集群方式 　　1、复制集 　　　　 　　缺点： 　　　　读写，都在主节点，性能不行。 　　2、分片（常用） 　　　　 上图中主要有如下所述三个主要组件： Shard: 用于存储实际的数据块，实际生产环境中一个shard server角色可由几台机器组个一个replica set承担，防止主机单点故障 Config Server: mongod实例，存储了整个 ClusterMetadata，其中包括 chunk信息。 Query Routers: 前端路由，客户端由此接入，且让整个集群看上去像单一数据库，前端应用可以透明使用。 来源： https://www.cnblogs.com/chen--biao/p/11666195.html

一：序 　　- 最近在对数据做缓存时候，会涉及到如何保证 数据库/Redis 一致性问题。 　　- 刚好今天来总结下 一致性问题 产生的问题，和可能存在的解决方案。 二：（更新策略）- 先更新数据库，后更新缓存 　　 - 产生的问题 　　　　- 　　　　- 由上面流程图可知道， 请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。 　　　　- 这就导致了 脏数据 ，因此不考虑 先更新数据库，后更新缓存 这个更新策略。 三：（更新策略）- 先删除缓存，在更新数据库 　　 - 产生的问题 　　　　- 　　　　- 如果同时有一个请求A进行更新操作，另一个请求B进行查询操作。 　　　　- 就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。 四：（更新策略）- 先更新数据库，在删除缓存 　　- FaceBook 也是采用这种方式。 　　- 当然，这种方式也会产生数据不一致问题。 　　　　- （1）缓存刚好失效 　　　　-（2）请求A查询数据库，得一个旧值 　　　　-（3）请求B将新值写入数据库 　　　　-（4）请求B删除缓存 　　　　-（5）请求A将查到的旧值写入缓存 　　- 前提是 写操作耗时一定是低于 读操作的，在一般的条件下，这时不可能得。 五：小结 　　- 这里只分析了平常可能想到的更新策略的分析。 　　- 其实

本文根据陈肃老师在 Apache Kafka x Flink Meetup 深圳站的分享整理而成，文章首先将从数据融合角度，谈一下 DataPipeline 对批流一体架构的看法，以及如何设计和使用一个基础框架。其次，数据的一致性是进行数据融合时最基础的问题。如果数据无法实现一致，即使同步再快，支持的功能再丰富，都没有意义。 另外，DataPipeline 目前使用的基础框架为 Kafka Connect。为实现一致性的语义保证，我们做了一些额外工作，希望对大家有一定的参考意义。 最后，会提一些我们在应用 Kafka Connect 框架时，遇到的一些现实的工程问题，以及应对方法。尽管大家的场景、环境和数据量级不同，但也有可能会遇到这些问题。希望对大家的工作有所帮助。 一、批流一体架构 批和流是数据融合的两种应用形态 下图来自 Flink 官网。传统的数据融合通常基于批模式。在批的模式下，我们会通过一些周期性运行的 ETL JOB，将数据从关系型数据库、文件存储向下游的目标数据库进行同步，中间可能有各种类型的转换。 另一种是 Data Pipeline 模式。与批模式相比相比， 其最核心的区别是将批量变为实时：输入的数据不再是周期性的去获取，而是源源不断的来自于数据库的日志、消息队列的消息。进而通过一个实时计算引擎，进行各种聚合运算，产生输出结果，并且写入下游。 现代的一些处理框架

MQ背景&选型 消息队列作为高并发系统的核心组件之一，能够帮助业务系统解构提升开发效率和系统稳定性。主要具有以下优势： 削峰填谷（主要解决瞬时写压力大于应用服务能力导致消息丢失、系统奔溃等问题） 系统解耦（解决不同重要程度、不同能力级别系统之间依赖导致一死全死） 提升性能（当存在一对多调用时，可以发一条消息给消息系统，让消息系统通知相关系统） 蓄流压测（线上有些链路不好压测，可以通过堆积一定量消息再放开来压测） 目前主流的MQ主要是Rocketmq、kafka、Rabbitmq，Rocketmq相比于Rabbitmq、kafka具有主要优势特性有： • 支持事务型消息（消息发送和DB操作保持两方的最终一致性，rabbitmq和kafka不支持） • 支持结合rocketmq的多个系统之间数据最终一致性（多方事务，二方事务是前提） • 支持18个级别的延迟消息（rabbitmq和kafka不支持） • 支持指定次数和时间间隔的失败消息重发（kafka不支持，rabbitmq需要手动确认） • 支持consumer端tag过滤，减少不必要的网络传输（rabbitmq和kafka不支持） • 支持重复消费（rabbitmq不支持，kafka支持） Rocketmq、kafka、Rabbitmq的详细对比，请参照下表格： RocketMQ集群概述 RocketMQ集群部署结构 image

来自：51CTO技术栈 例如：单表中出现了，动辄百万甚至千万级别的数据。“分表分库”就成为解决上述问题的有效工具。 今天和大家一起看看，如何进行分表分库以及期间遇到的问题吧。 为什么会分表分库 数据库数据会随着业务的发展而不断增多，因此数据操作，如增删改查的开销也会越来越大。 再加上物理服务器的资源有限（CPU、磁盘、内存、IO 等）。最终数据库所能承载的数据量、数据处理能力都将遭遇瓶颈。 换句话说需要合理的数据库架构来存放不断增长的数据，这个就是分库分表的设计初衷。目的就是为了缓解数据库的压力，最大限度提高数据操作的效率。 数据分表 如果单表的数据量过大，例如千万级甚至更多，那么在操作表的时候就会加大系统的开销。 每次查询会消耗数据库大量资源，如果需要多表的联合查询，这种劣势就更加明显了。 以 MySQL 为例，在插入数据的时候，会对表进行加锁，分为表锁定和行锁定。 无论是哪种锁定方式，都意味着前面一条数据在操作表或者行的时候，后面的请求都在排队，当访问量增加的时候，都会影响数据库的效率。 那么既然一定要分表，那么每张表分配多大的数据量比较合适呢？这里建议根据业务场景和实际情况具体分析。 一般来说 MySQL 数据库单表记录最好控制在 500 万条（这是个经验数字）。既然需要将数据从一个表分别存放到多个表中，那么来看看下面两种分表方式吧。 垂直分表 根据业务把一个表中的字段