数据库一致性

项目常见面试问题 阅读目录 项目常见面试问题 回到目录 项目常见面试问题 一、你的项目中缓存粒度是如何选择的? 缓存粒度一共分为4种. 1.缓存某个数值:一个键只保存一个值,性价比较低,使用率低,如果存储的话我们使用redis的String 2.缓存数据对象:数据库记录对应的具体数据,优点是可以多次复用,String,hash 3.缓存数据集合:数据库查询对应的结果集,可以和数据对象配合使用,方便数据对象的重用,hash,list,set,zset,String(zset,String) 4.缓存试图响应:试图返回的相应数据,复用性比较差,String 所以我们项目中主要对数据集合+数据对象进行缓存,他们的优点是复用性强,节省内存空间. 二、使用过redis的那些格式做过缓存,其他应用场景和优缺点是什么? 包括list,zset,set,hash和json字符串 其中我们使用过json字符串和zset set用来存放无序去重的数据, 如果有判断是否存在的需求 zset有排序的需要list,如果说是按时间查询, 查询的结果固定, 不需要分页的情况下,我们使用list因为查询的比较快 但如果有额外排序要求, 而且需要分页, 我们使用zset(查询时间跟查询的长度和数据量有关,跟查询区别无关, 查询速度比较均衡), 增加数据效率和存储的数据量负相关,数据量越大,添加时间越长

这个怎么说呢？？？网上说的天花乱坠，说什么的都有，很早以前我感觉我理解了，现在回过头完全不知.... 首先我先描述下CAP，然后再详细解释。 1、可用性，也就是所谓的A（Consistency） 是指系统中任何一个节点宕机，其他节点也可以继续对外正常（此处待议）提供服务。 2、一致性，也就是所谓的C（Availability） 这个是比较好理解的，是指数据在任何时候，读取数据都是一致的，此处一致性指的是强一致性。 3、分区容忍性，也就是所谓的P（Partition tolerance） 这个是比较抽象点，分区容忍性强调是指系统中的节点因网络原因中断连接，导致出现分区现象，可以理解原本是整体，节点之间相互交互。出现这个现象和可用性不同地方在于，都可对外提供服务，但因出现分区，如果数据分区存储，就会出现对外提供数据异常。 争议问题 可用性： 什么算可用？什么算不可用？我程序出现异常，返回一个程序异常提示，算可用？如果算，那这个可用性就好处理了，处理不了我就都返回，那我就可以说我的程序是可用的？？？还是说可用指的是可以正常的业务场景处理，A、B两节点，A节点宕掉，B节点可以继续处理请求。所以，理解不同导致网上说法也大不一样。 一致性： 一致性是指强一致性，虽然时间差距在毫秒也不可否认有差距。大部分主从结构都是这样的，写入主节点后，会有线程会将数据写一份给从库

工作中，经常会遇到缓存和数据库数据一致性问题。从理论上设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。因此，接下来讨论的思路不依赖于给缓存设置过期时间这个方案。 在这里，我们讨论三种更新策略： 1) 先更新数据库，再更新缓存 2) 先删除缓存，再更新数据库 3) 先更新数据库，再删除缓存 (1) 先更新数据库，再更新缓存 这套方案，大家是普遍反对的。为什么呢？有如下两点原因。 原因一（线程安全角度） 同时有请求A和请求B进行更新操作，那么会出现 （1）线程A更新了数据库 （2）线程B更新了数据库 （3）线程B更新了缓存 （4）线程A更新了缓存 这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存。这就导致了脏数据，因此不考虑。 原因二（业务场景角度） 有如下两点： （1）如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能。 （2）如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后

开发单体应用时，相信大家都有使用过数据库的 本地事务 ，也就是在同一个数据库中，可以允许一组操作要么全都正确执行，要么全都不执行。这里特别指出了本地事务，也就是说明数据库事务只支持同一个数据库的操作。可随着技术和业务发展，一方面随着系统业务量增大，数据库存储东西越来越多。当达到一定数据量时，为了应对高并发，就会出现分库分表需求。另一方面，随着服务化方案的推广，越来越多的公司团队将原有的大项目拆分成一个个小应用，这也使得跨应用（JVM）数据库场景出现。可是目前数据库不支持跨库事务，我们应该如何实现分布式事务呢？本文首先会为大家梳理分布式事务的基本概念和理论基础，然后介绍几种目前常用的分布式事务解决方案。 一、定义 百度百科给出的定义：“分布式事务就是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。”简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 二、事务的四大特性 ACID 1.原子性 原子性要求，事务是一个不可分割的执行单元，事务中的所有操作要么全都执行，要么全都不执行。 2.一致性 一致性要求，事务在开始前和结束后，数据库的完整性约束没有被破坏。 3.隔离性

历史优质文章： 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机（jvm）的问题看这篇就够了 Java NIO 概览 分布式系统设计理念 分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。 分布式系统的目标与要素 分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。 即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。 分布式系统设计两大思路：中心化和去中心化 1）中心化设计： 两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上分为两种角色： “领导” 和 “干活的” 角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。 中心化设计的问题 ： 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题

【背景】 随着单体应用的缺陷日益明显，越多越多的公司都从传统的单体应用模式向新型的分布式应用模式转变。 实际上，在分布式应用带来巨大优势的同时，也伴随着各种挑战。例如，系统容错、网络延迟和分布式事务等。 本篇博客开始，将会对分布式事务做一系列学习总结。从本篇博客，我们可以了解到什么是分布式事务，关于分布式事务的相关理论以及处理分布式事务的解决方案。 【本地事务】 在没有接触分布式应用前，我们接触到的事务一般都是本地事务，即在单个数据库并且限制在单个进程内的事务。本地事务不涉及多个数据源。 若我们的系统使用了spring，一般加上@Transition注解即可保证事务正常运行。但如果是分布式系统应用下，若操作涉及不同的数据库，这样本地事务就失效了，从而就涉及到了分布式事务。 【分布式事务】 1. 什么是分布式事务 分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于不同的分布式系统的不同节点之上。 简单的说，就是一次大的操作由不同的小操作组成，这些小的操作分布在不同的服务器上，且属于不同的应用，分布式事务需要保证这些小操作要么全部成功，要么全部失败。本质上来说，分布式事务就是为了保证不同数据库的数据一致性。 2. 分布式事务的产生原因 从原来的单体应用到分布式应用的转变，便意味着从以前的一个系统到多个服务共同组成一个系统的转变。 如一个电商系统，拆分为订单

引言 狭义的分布式系统指由网络连接的计算机系统，每个节点独立地承担计算或存储任务，节点间通过网络协同工作。广义的分布式系统是一个相对的概念，正如Leslie Lamport所说[1]： What is a distributed systeme. Distribution is in the eye of the beholder. To the user sitting at the keyboard, his IBM personal computer is a nondistributed system. To a flea crawling around on the circuit board, or to the engineer who designed it, it’s very much a distributed system. 一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。下面我们从一致性问题、特定条件下解决一致性问题的两种方法(2PC、3PC)入门，了解最基础的分布式系统理论。 一致性(consensus) 何为一致性问题？简单而言，一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中，进行数据库事务提交(commit transaction)

ACID: 　　- Atomicity: the transaction is either completely or not at all. For this, the beginning of the transaction is marked with the BEGIN command, and the end is either COMMIT (commit changes) or ROLLBACK (undo changes). 　　- Consistency: the transaction begins in a consistent state and, completing, also maintains consistency. 　　- Isolation: other transactions running at the same time with this one should not affect it. 　　- Durability: after the data are recorded, they should not be lost even in case of failure. 一致性是指数据处于一种语义上的有意义且正确的状态。一致性是对数据可见性的约束，保证在一个事务中的多次操作的数据中间状态对其他事务不可见的。因为这些中间状态

1.ACID特性 数据库管理系统中事务(transaction)的四个特性： 原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability） 1、原子性 原子性是指事务是一个不可再分割的工作单元，事务中的操作要么全部成功，要么全部失败。 2、一致性 一致性是指在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。这是说数据库事务不能破坏关系数据的完整性以及业务逻辑上的一致性。 3、隔离性 多个事务并发访问时，事务之间是隔离的，一个事务不应该影响其它事务运行效果。 4、持久性 持久性，意味着在事务完成以后，该事务对数据库所作的更改便持久的保存在数据库之中，并不会被回滚。 2.CAP理论 CAP理论，指的是在一个分布式系统中，不可能同时满足Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性）这三个基本需求，最多只能满足其中的两项。 1、一致性： 指数据在多个副本之间是否能够保持一致的特性。当执行数据更新操作后，仍然可以保证系统数据处于一致的状态。 2、可用性： 系统提供的服务必须一直处于可用的状态。对于用户的每一个操作请求总是能够在“有限的时间内”返回结果。这个有限时间是系统设计之初就指定好的系统运行指标

这篇文章将介绍什么是分布式事务，分布式事务解决什么问题，对分布式事务实现的难点，解决思路，不同场景下方案的选择，通过图解的方式进行梳理、总结和比较。相信耐心看完这篇文章，谈到分布式事务，不再只是有“2PC”、“3PC”、“MQ的消息事务”、“最终一致性”、“TCC”等这些知识碎片，而是能够将知识连成一片，形成知识体系。 什么是事务 介绍分布式事务之前，先介绍什么是事务。 事务的具体定义 事务提供一种机制将一个活动涉及的所有操作纳入到一个不可分割的执行单元，组成事务的所有操作只有在所有操作均能正常执行的情况下方能提交，只要其中任一操作执行失败，都将导致整个事务的回滚。 简单地说，事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。 数据库事务的 ACID 属性 事务是基于数据进行操作，需要保证事务的数据通常存储在数据库中，所以介绍到事务，就不得不介绍数据库事务的 ACID 特性。 ACID 指数据库事务正确执行的四个基本特性的缩写，包含： 原子性（Atomicity） 整个事务中的所有操作，要么全部完成，要么全部不完成，不可能停滞在中间某个环节。 事务在执行过程中发生错误，会被回滚（Rollback）到事务开始前的状态，就像这个事务从来没有执行过一样。 例如：银行转账，从 A 账户转 100 元至 B 账户，分为两个步骤：从 A 账户取 100 元。存入