脏数据

一、 数据概念 1、 脏数据所指的就是未提交的数据。也就是说，一个事务正在对一条记录做修改，在这个事务完成并提交之前，这条数据是处于待定状态的（可能提交也可能回滚），这时，第二个事务来读取这条没有提交的数据，并据此做进一步的处理，就会产生未提交的数据依赖关系。这种现象被称为脏读。 2、 不可重复读（ Non-Repeatable Reads）：一个事务先后读取同一条记录， 而事务在两次读取之间该数据被其它事务所修改，则两次读取的数据不同，我们称之为不可重复读。 3、 幻读（ Phantom Reads）：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务插入了满足其查询条件的新数据，这种现象就称为幻读。 4 、幻读是指当事务不是独立执行时发生的一种现象，例如第一个事务对一个表中的数据进行了修改，比如这种修改涉及到表中的 “全部数据行”。同时，第二个事务也修改这个表中的数据，这种修改是向表中插入“一行新数据”。那么，以后就会发生操作第一个事务的用户发现表中还存在没有修改的数据行，就好象发生了幻觉一样.一般解决幻读的方法是增加范围锁RangeS，锁定检索范围为只读，这样就避免了幻读。 二、数据库事务的四大特性： 1 、原子性：事务包含的所有数据库操作要么全部成功，要不全部失败回滚 2 、一致性：一个事务执行之前和执行之后都必须处于一致性状态。拿转账来说，假设用户

一 前言 首先，缓存由于其高并发和高性能的特性，已经在项目中被广泛使用。在读取缓存方面，大家没啥疑问，都是按照下图的流程来进行业务操作 但是在更新缓存方面，对于更新完数据库，是更新缓存呢，还是删除缓存。又或者是先删除缓存，再更新数据库，其实大家存在很大的争议 本文由以下三个部分组成 1、讲解缓存更新策略 2、对每种策略进行缺点分析 3、针对缺点给出改进方案 回到目录 二 一致性方案 先做一个说明，从理论上来说，给缓存设置过期时间，是保证最终一致性的解决方案。这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可。也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存。因此，接下来讨论的思路不依赖于给缓存设置过期时间这个方案。 在这里，我们讨论 三种 更新策略： 1. 先更新数据库，再更新缓存 2. 先删除缓存，再更新数据库 3. 先更新数据库，再删除缓存 回到目录 三 先更新数据库，再更新缓存 这套方案，大家是普遍反对的。为什么呢？有如下两点原因。 原因一（线程安全角度） 同时有请求A和请求B进行更新操作，那么会出现 （1）线程A更新了数据库 （2）线程B更新了数据库 （3）线程B更新了缓存 （4）线程A更新了缓存 这就出现请求A更新缓存应该比请求B更新缓存早才对

大道至简的数据治理方法论——如何处理你手中的各种“脏数据”？ 如果你是一位大厨，刚刚眉飞色舞地给客人描绘了如何搭配一道色香味俱佳的大菜，甚至连炒菜的手法都一一交代了，当你备好了各种为这道菜增鲜增色的调料后准备烹饪时，才发现所需的主要原料有问题。 数据分析师的角色犹如一位大厨，原料有问题，大厨肯定烹饪不出色香味俱佳的大菜，数据有问题，数据分析师得出的结论自然也就不可靠，再好的数据分析方法论也只是建立在失真的数据基础上，苦心构建的数据体系当然也被白白浪费了。 过往的项目中，笔者也时常遇到这样的情况，客户用永洪科技的产品做了一些精美专业的数据报告，却因数据不准而影响了报告的使用价值。 前两篇文章笔者分别探讨了面对数据指标如何分析，以及如何构建系统化的数据体系，本文是“数据化运营方法论系列”文章的第三篇，重点探讨的核心话题是——数据治理。 第一篇 《大道至简的数据分析方法论》 第二篇 《大道至简的数据体系构建方法论》 数据治理是一项基础工作，在很多人眼中是一项苦活儿累活儿，但是越是这样的工作越是不能忽视，基础打扎实了，上层建筑才会更稳固。 下面，笔者先从脏数据的种类及处理方法谈起。 一、脏数据的种类及处理方法 首先，我们来了解一下脏数据的种类，明白我们可能会面对哪些问题。 1 数据缺失：缺一些记录，或者一条记录里缺一些值（空值），或者两者都缺。原因可能有很多种

一. 先聊点别的 　　1. sql & nosql 　　　sql指关系型数据库，如Oracle，MySQL等，nosql泛指非关系型数据库，如MongoDB，Redis等；SQL数据存在特定结构的表中，而NoSQL则更加灵活和可扩展，存储方式可以是JSON文档，哈希表或其他方式；在sql中必须定义好表和字段结构后才能添加数据，如主键，索引，触发器，存储过程等，表结构虽然可以在定义之后被更新，但是如果有比较大的结构变更的化就会变得比较复杂，在nosql中，数据可以在任何时候任何地方添加，不需要先定义表，nosql也可以在数据集中船舰索引；综上：nosql更加适合初始化数据还不明确或者未定的项目中。 　　2. ACID & CAP & BASE 　　ACID是指在数据库管理系统中，事务所具有的四个特性：原子性，一致性，隔离性，持久性； 　　CAP是指一致性，可用性和分区容错性，CAP理论指这三个要素最多只能实现两个； 　　BASE接受最终一致性的理论支持，BasicallyAvalable基本可用，Soft-state软状态/柔性事务，EventuallyConsistency最终一致性； 二. Redis：REmote DIctionary Server（远程字典服务器） 1. 什么是Redis？有什么优点？ 　　Redis是存储kv数据结构的分布式数据库； 　　a. 读写速度快

原创 2016-12-06 58沈剑+GitChat 架构师之路 架构师之路 架构师之路 微信号 功能介绍 架构师之路，坚持撰写接地气的架构文章 前段时间，受@谢工 邀请，在GitChat平台首发《 究竟啥才是互联网架构“高可用” 》。 12月01日周四晚8点30分，在微信群进行了针对该文章的的主题交流。以下是主持人 @赫阳 整理的问题精华，记录下了我和读者之间关于高可用架构的问答精彩片段。 问答中所有文章都是可以直接点击跳转的哟。 问：在缓存层rehash过程中必然会有脏数据。一致性hash实际上只能减少rehash的成本，不能消灭脏数据，这种脏数据有没有办法避免？ 答：如文章《 究竟啥才是互联网架构“高可用” 》所述，如果没有高可用需求，一台 cache 挂了，不宜做rehash，会产生脏数据。此时对挂掉cache的key可以直接返回 cache miss。 问：从您后面的回答来看，这其实也是“降级”的一种，这样以后是直接把请求打到后端的数据库上么？还是直接抛弃请求？如果发生雪崩效应，miss的请求越来越多，如果miss的都打库的话，库马上就会挂了。 这一块老师能再展开讲一讲么？ 答：打到数据库上，cache集群的份数和数据库能抗多少读有关。理论上1-2份挂掉，数据库能抗住。58的做法，有一个 backup mc集群，有挂了可以顶上，不建议rehash。高可用的代价是冗余

1 、背景 Redis的出现确实大大地提高系统大并发能力支撑的可能性，转眼间Redis的最新版本已经是3.X版本了，但我们的系统依然继续跑着2.8，并很好地支撑着我们当前每天5亿访问量的应用系统。想当年Redis的单点单线程特性无法满足我们日益壮大的系统，只能硬着头皮把Redis“集群化”负载。且这套“集群化”方案良好地运行至今。虽难度不高，胜在简单和实用。无论简单还是很简单，记录这种经历是一件非常有趣的事情。 2 、问题 系统访问量日益倍增，当前的Redis单点服务确实客观存在连续可用性以及支撑瓶颈风险，这种主/备模式在服务故障突发的情况下就会被动停止服务进行Redis节点切换。针对单点问题，我们结合自身的业务应用场景对Redis“集群化”提出几个主要目标： 1、避免单点情况，确保服务高可用； 2、紧可能把数据分布式存储，降低故障影响范围，满足服务灵活伸缩； 3、控制“集群化”的复杂度，从而控制边际成本； 3 、过程 以上目标1和2就是所谓的分布式集群方案，把大问题分而治之。但最难把控的是目标3的“简化”实现。基于当时开源社区的那几种Redis集群方案，对于我们“简化”的要求来说相对略显臃肿。所以还是决定结合自身的业务应用等因素打造一个“合适”的Redis集群。 初始，我们凭借自己对分布式集群的认识勾结合应用场景勾勒出一个我们觉得足够“简化”的设计图，然后在这个“简化

1.使用缓存的场景 缓存是提高系统读性能的常用技术，尤其对于读多写少的应用场景，使用缓存可以极大的提高系统的性能 例子：查询用户的存款： select money from user where uid = YYY; 为了优化该查询功能，我们可以在缓存中建立uid->money的键值对。 减少数据库的查询压力。 2. 读操作流程 目前数据库和缓存中都有存储数据，当读取数据的时候，流程如下。 1）先读取缓存是否存在数据(uid->money)。如果缓存中有数据返回结果。 2）如果缓存中没有数据，则从数据库中读取数据。 介绍一个概念： 缓存命中率：缓存命中数/总缓存访问数。 3. 写操作流程 在介绍写操作流程之前，先讨论两个问题 问题一：淘汰缓存还是更新缓存？ 淘汰缓存：数据只会写入数据库，不会写入缓存，只会把数据淘汰掉。 更新缓存：数据不但写入数据库，还会写入缓存。 问题二：先写缓存还是先写数据库？ 由于对缓存的更新和数据库的更新无法保证事务性操作。一定涉及到哪个先做，哪个后做的问题，我们的原则是采取对业务影响小的策略。下面是四种不同的组合策略 由此可见第四种策略的影响最小，只会造成一次查询缓存miss而已。那么当查询缓存miss的时候，我们该怎么办？很简单，查询数据库，然后将数据库的内容更新到缓存中。可能有人会问第四种策略，如果一上来淘汰缓存就失败了怎么办，当然是直接返回即可

作者：Infinities Loop 概述 ViewState是一个被误解很深的动物了。我希望通过此 文章来澄清人们对ViewState的一些错误认识。为了达到这个目的，我决定从头到尾详细的描述一下整个ViewState的工作机制，其中我会同时用 一些例子说明我文章中的观点，结论。比如我会用静态控件(declared controls)和动态控件(dynamic controls)两个方面来说明同一个问题。 现在有关ViewState的文章可谓多如牛毛，你可能会说 再写有关ViewState的文章无异于炒剩饭(我这篇文章便是:D)。但是我却不这么认为，如果把ViewState看成一匹野马的话，那么这匹野马并 没有死去，它还活跃的很，说不定这个时候它正在你的客厅里撒野呢。所以我们有必要再次去把它击倒。不过你也不需要担心，从这篇文章你可以发现其实这匹马也 没有那么坏。 我的意思并不是否然目前还没有好好说明ViewState的 文章，只是我总觉得好像这些文章都缺少一些东西，而这些缺少的东西往往就会导致人们对ViewState的困惑。比如：理解ViewState是怎样跟踪 那些已经出现变化的数据(dirty data)就非常重要，但是很多文章却没有过多的涉及，或者即便涉及了可能其中却包含了错误的信息。比如这篇文章( W3Schools ) 中就说页面回传的值也是保存在ViewState中的

缓存模式 1） Cache Aside 更新方式 先更新数据库，再更新缓存。这种做法最大的问题就是两个并发的写操作导致脏数据 。如下图（以Redis和Mysql为例），两个并发更新操作，数据库先更新的反而后更新缓存，数据库后更新的反而先更新缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是脏数据。 先删除缓存，再更新数据库。这个逻辑是错误的，因为两个并发的读和写操作导致脏数据 。如下图（以Redis和Mysql为例）。假设更新操作先删除了缓存，此时正好有一个并发的读操作，没有命中缓存后从数据库中取出老数据并且更新回缓存，这个时候更新操作也完成了数据库更新。此时，数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。 先更新数据库，再删除缓存。 这种做法其实不能算是坑，在实际的系统中也推荐使用这种方式。但是这种方式理论上还是可能存在问题。如下图（以Redis和Mysql为例），查询操作没有命中缓存，然后查询出数据库的老数据。此时有一个并发的更新操作，更新操作在读操作之后更新了数据库中的数据并且删除了缓存中的数据。然而读操作将从数据库中读取出的老数据更新回了缓存。这样就会造成数据库和缓存中的数据不一致，应用程序中读取的都是原来的数据（脏数据）。 但是，仔细想一想，这种并发的概率极低。因为这个条件需要发生在读缓存时缓存失效，而且有一个并发的写操作

缓存能解决的问题 提升性能 绝大多数情况下，select 是出现性能问题最大的地方。一方面，select 会有很多像 join、group、order、like 等这样丰富的语义，而这些语义是非常耗性能的；另一方面，大多 数应用都是读多写少，所以加剧了慢查询的问题。 分布式系统中远程调用也会耗很多性能，因为有网络开销，会导致整体的响应时间下降。为了挽救这样的性能开销，在业务允许的情况（不需要太实时的数据）下，使用缓存是非常必要的事情。 缓解数据库压力 当用户请求增多时，数据库的压力将大大增加，通过缓存能够大大降低数据库的压力。 缓存的适用场景 对于数据实时性要求不高 对于一些经常访问但是很少改变的数据，读明显多于写，适用缓存就很有必要。比如一些网站配置项。 对于性能要求高 比如一些秒杀活动场景。 缓存三种模式 一般来说，缓存有以下三种模式： Cache Aside 更新模式 Read/Write Through 更新模式 Write Behind Caching 更新模式 缓存的各种操作 写就是更新，更新就是写。 读 R_1：先读缓存，读到了缓存则返回，读不到缓存则去读数据库，直接返回读到数据，不操作缓存 R_2：先读缓存，读到了缓存则返回，读不到缓存则去读数据库，将数据库中读到的数据更新到缓存中 写 W_1：先写缓存，再写数据库 W_2：先写数据库，库再写缓存 W_3：先删除缓存