fsync

大纲 为什么要做数据持久化 数据持久化方式（RDB 和 AOF 介绍） RDB 的优缺点 AOF 的优缺点 开篇 本文着重讲得是 redis 数据持久化，不会去介绍 redis 是什么，它的特性是什么，以及安装方式，使用场景等等。 正文 一. 为什么要做数据持久化 或者我们还可以这样问，什么情况下需要做数据持久化？ 这需要结合你的业务场景去选择，当然大部分情况下，还是建议大家去做 redis 的数据持久化。 回到原题，我们做数据持久化的目的是用于故障恢复。 举个例子： 我最近接手到的 xx 系统，它的数据就直接存在 redis 中，或者说我们就是把 redis 当作一个持久化数据库在用，这样做的原因就先不说了。根据这样一个应用场景，假设我们不做数据持久化，万一 redis 挂掉，我们的数据就全没了，如何跟客户去交代？？？ ～～～～～ 只能跑路～～～ 那么问题又来了， redis 是怎么做数据持久化的？ 如果我们做了数据持久化，就能保证一条数据都不会丢了吗？ 请接着往下看 ⬇️️️ 二. redis 数据持久化方式 redis 提供了两种不同的持久化方式： RDB 和 AOF。 RDB ： 定期保存一份 redis 快照数据到 rdb 文件当中 AOF ： 把每一个写操作都记录在一个日志文件里 说的通俗一点就是： RDB 就是将 redis 的数据保存到一份 rdb 文件中

前言 上篇大致介绍了 ElasticSearch CRUD 的数据走向和涉及到的 Gossip 算法和每一种节点扮演的角色。我们对 ES 有了初步的认知，这一篇着重从 CAP 的角度去解读 ES 的分布式思想。 一、Split Brain 之前介绍过，对于去中心化的 ES 分布式系统来说，采用默认配置是无法避免脑裂问题的（可以参考前一篇文章的 discovery.zen.minimum_master_nodes 参数）。当然，任何分布式系统都是不能够接受脑裂的情况出现的，因此这里我们不过多讨论 P（分区容错性）。 既然不讨论 P，那么 ES 到底属于 CP 还是 AP 设计呢？ 我的理解是，脱离了具体配置谈 CAP 都是扯淡。 为什么这么说呢？在我看来，AP 和 CP 并没有很明确的界限，一切根据配置而论，而配置本身会根据业务场景在 AP 与 CP 之间做一个折衷，即所谓的 Trade-Off。 二、读主分片 or 读副本 读数据的时候我们可以根据 Preference 指定读取的分片类型 参数 描述 _primary 只会在主分片操作 _primary_first 优先主分片操作，如果主分片不可用，就会找其他分片操作 _replica 只会在副本分片操作 _replica_first 优先副本分片操作，如果副本分片不可用，就会找其他分片操作 _local 尽可能在本地分片操作

背景 由于mysql的innodb引擎对于数据文件和日志文件都有自己的内存缓冲，在真正写入磁盘时，完全可以不使用os的io缓冲机制（避免双缓冲的冗余浪费）。 所以mysql提供了对应的参数innodb_flush_method来控制对文件写入的方式，当innodb_flush_method=O_DIRECT就能绕过os的缓冲，是比较推荐的一种选项。 innodb_flush_method几个选项的解析 首先让我们忘记mysql，先来看下linux os提供的文件操作方式 open文件的三种模式 O_DIRECT，O_SYNC，O_DSYNC以及default模式（当然可选的远不止这四个，由于本文不涉及其他的，就忽略介绍了） default每次读写都会使用os缓冲，写时不保证数据落入磁盘 O_DIRECT每次读写文件时是直接向磁盘写入，绕过os缓冲，但是返回的时候不保证数据和元数据信息已经完全刷入磁盘 O_SYNC仍然会使用os的缓冲，只不过在每次写的时候强制将缓冲刷入磁盘(包括所有元数据信息) O_DSYNC仍然会使用os的缓冲，只不过在每次写的时候强制将缓冲刷入磁盘(包括部分元数据信息) O_DSYNC相较于O_SYNC，可能会减少磁盘操作次数，因为元数据和文件数据可能在磁盘的不同区域，O_DSYNC可以减少这部分元数据的磁盘操作。 上面是open打开文件的系统调用

前言 这篇文章主要介绍Elasticsearch的索引工作机制,它是如何利用translog来保证数据的安全,以及我们在生产环境中如何优化translog的参数来最大化性能,主要会介绍到elastic中常见的2个操作:refresh和flush，以及这2个接口是如何保证数据能够被检索到的。 一、数据持久化 我们把数据写到磁盘后,还要调用fsync才能把数据刷到磁盘中,如果不这样做在系统掉电的时候就会导致数据丢失,这个原理相信大家都清楚,elasticsearch为了高可靠性必须把所有的修改持久化到磁盘中。 elastic底层采用的是lucene这个库来实现倒排索引的功能,在lucene的概念里每一条记录称为document(文档),lucene使用segment(分段)来存储数据,用commit point来记录所有segment的元数据，一条记录要被搜索到,必须写入到segment中,这一点非常重要,后面会介绍为什么elastic搜索是near-realtime(接近实时的)而不是实时的。 elastic使用translog来记录所有的操作,我们称之为write-ahead-log，我们新增了一条记录时，es会把数据写到translog和in-memory buffer(内存缓存区)中,如下图所示: 内存缓存区和translog就是near-realtime的关键所在

今天和大家唠唠大名鼎鼎的 Redis 。Redis其实是一款用C语言编写的、高性能的Key-Value数据库。由于她具有极佳的读写性能，往往会被当作缓存组件来使用。Redis的作者是来自西西里岛的一个帅小伙，全名：Salvatore Sanfilippo（网名：antirez），目前供职于 Pivotal 公司。这一说到Pivotal可又牵出个大瓜来，朱哥忍不住要说到说到了！小伙伴们可能对Pivotal不太熟悉，那是主要是因为人家在咱国内比较低调。而在大洋彼岸，Pivotal的故事可是相当传奇啊！由于剧情过于狗血，先来看看朱哥梳理的时间脉络： 1979年，EMC公司立于美国麻州Hopkinton市； 1984年，19岁的迈克尔.戴尔先生以1000美元资金创立了戴尔计算机公司； 1989年，Rob Mee 创立的咨询公司 Pivotal Labs； 1998年，VMware公司成立于美国加利福尼亚州帕洛阿尔托市； 2003年，Rod Johnson和同伴创建了Spring 开源项目； 2004年，Rod Johnson和同伴创建interface21公司以支持Spring开发； 2004年，EMC以 6.35亿美元收购VMware； 2007年，interface21公司更名为 SpringSource公司； 2009年，VMware以4.2亿美元收购SpringSource；

前言 Redis是基于内存操作的单线程缓存中间件。 一 RDB快照(snapshot) 在默认情况下，Redis将内存数据库快照保存在dump.rdb二进制文件中， Redis服务重新启动时根据dump.rdb文件重写Redis内存。 dump.rdb文件默认在redis安装目录下面。 可以在redis.conf中对redis快照频率进行设置。 1、save设置语法 save <seconds> <changes> 语法含义： N秒内至少有M个变动，则自动保存一次数据快照。 比如，save 10 1，即10秒内，发生至少一次变动，则自动保存一次数据快照。 2、redis.conf修改配置 配置修改后要记得重启redis服务，让配置生效。 3、实例验证 把dump.rdb文件删掉，redis-cli连接客户端，然后进行简单set操作。 然后在redis安装目录可以看到新生成的dump.rdb文件。 dump.rdb文件内容为二进制。 如果我们再把dump.rdb文件清掉，杀掉redis进程，重新启动redis，我们会发现刚才set的key1在redis里面 没有了，因为dump.rdb被清掉了，redis重启时就恢复不了数据，所以redis重启后找不到key1。 反之，则能找到key1。 二 AOF(append only file) rdb快照是达到条件之后进行dump.rdb备份

开篇 本文跟上一篇 Redis 数据持久化 - RDB 和 AOF 简单介绍 紧密相关，主要介绍 redis 数据持久化如何配置，以及上一篇文章中存在的问题。 正文 redis 的核心配置配置是 redis.conf ,本文是基于 redis-4.0.6 版本讲解。 RDB 数据持久化配置 默认情况下，redis 中的 RDB 数据持久化是开启的。 在 redis.conf 有如下一段默认配置： save 900 1 save 300 10 save 60 10000 # 可自行定义（不推荐更改），格式如下： # save <seconds> <changes> 配置说明： 比如 save 60 10000 表示如果 60s 内，有 10000 个 key 发生了改变，就保存一次快照，并且每次生成一个新的快照，都会覆盖之前的老快照。 补充： 通过 redis-cli SHUTDOWN 命令去停掉redis，redis 在退出的时候会将内存中的数据立即生成一份完整的 rdb 快照 可以手动调用 save 或者 bgsave 命令，同步或异步执行 rdb 快照生成 把上面三行配置注释或者删除掉，就可以关闭 RBD 持久化 AOF 数据持久化配置 AOF持久化，默认是关闭的。 打开 redis.conf, 找到如下配置 appendonly no # 改为 yes 就开启了 AOF

持久化就是把内存的数据写到磁盘中去,防止服务宕机内存数据丢失 redis提供了两种持久化方式,RDB(默认)和AOF 宕机 : down机,指操作系统无法从一个严重系统错误中恢复过来,或系统硬件层面出现问题,以致系统长时间无响应,而不得不重新启动计算机的现象,它属于电脑运作的一种正常现象,任何电脑都会出现这种情况 RDB : rdb是Redis DataBase缩写 功能核心函数rdbSave(生成RDB文件)和rdbLoad(从文件加载内存)两个函数 AOF : aof是Append-only file缩写 每当执行服务器(定时)任务或者函数时flushAppendOnlyFile 函数都会被调用,这个函数执行一下两个工作 aof 写入保存 WRITE : 根据条件,将aof_buf中的缓存写入到AOF文件 SAVE : 根据条件,调用fsync或fdatasync函数,将AOF文件保存到磁盘中 存储结构 内容是redis通讯协议(RESP)格式的命令文本存储 比较 aof 文件比rdb更新频率高,优先使用aof还原数据 aof 比rdb更安全也更大 rdb性能比aof好 如果两个都配置了优先加载aof 注:内容皆为摘抄 来源： oschina 链接： https://my.oschina.net/u/4253180/blog/3158110