fsync

通过上一篇文章，对MySQL的内部结构以及一条查询语句是如何执行的有了一个大概的认识。下面对MySQL的更新以及两个日志文件进行总结。 如图： 以上是一张MySQL更新的执行示意图。这张图较好地解释了一条sql是如何执行的。下面先对图中比较陌生的元素 redo log 和 binlog 进行介绍。 redo log： 翻译过来就是重做日志，是Innodb存储引擎特有的（Innodb原先是另外一家公司以插件形式加入到MySQL中），它是物理日志，只有Indobd能使用，记录的是“在某个数据页上做了什么修改”。它是一个环形，说明它是有固定大小的，从头写到末尾就要擦出一部分之后才能继续写。这边有一个 WAL 技术，后面再做详情介绍。 binlog： 翻译过来就是归档日志，在MySQL的server层，所以是所有存储引擎都共有的，它是逻辑日志，可以给别的数据库，引擎使用，记录的是这个语句的原始逻辑，如“给id=1的这一行的某个字段+1”。它不是环形，它是一直追加写入的，不会覆盖以前的日志。 WAL 技术： Wirte-Ahead logging，直译就是“先写日志”。为什么要先写日志呢？在MySQL中，我们的数据页有可能在内存中，也有可能在磁盘中，如果我们每次更新都去写磁盘，那么MySQL的更新操作的效率会很低。并且写日志时按照顺序写，可以以组的方式提交

在一些网络服务的系统中，Redis 的性能，可能是比 MySQL 等硬盘数据库的性能更重要的课题。比如微博，把热点微博[1]，最新的用户关系，都存储在 Redis 中，大量的查询击中 Redis，而不走 MySQL。 那么，针对 Redis 服务，我们能做哪些性能优化呢？或者说，应该避免哪些性能浪费呢？ Redis 性能的基本面 在讨论优化之前，我们需要知道，Redis 服务本身就有一些特性，比如单线程运行。除非修改 Redis 的源代码，不然这些特性，就是我们思考性能优化的基本面。 那么，有哪些 Redis 基本特性需要我们考虑呢？Redis 的项目介绍中概括了它特性： Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported. 首先，Redis 使用操作系统提供的虚拟内存来存储数据。而且，这个操作系统一般就是指 Unix。Windows 上也能运行 Redis，但是需要特殊处理。如果你的操作系统使用交换空间，那么 Redis 的数据可能会被实际保存在硬盘上。 其次，Redis 支持持久化，可以把数据保存在硬盘上。很多时候，我们也确实有必要进行持久化来实现备份，数据恢复等需求

在一些网络服务的系统中，Redis 的性能，可能是比 MySQL 等硬盘数据库的性能更重要的课题。比如微博，把热点微博[1]，最新的用户关系，都存储在 Redis 中，大量的查询击中 Redis，而不走 MySQL。 那么，针对 Redis 服务，我们能做哪些性能优化呢？或者说，应该避免哪些性能浪费呢？ Redis 性能的基本面 在讨论优化之前，我们需要知道，Redis 服务本身就有一些特性，比如单线程运行。除非修改 Redis 的源代码，不然这些特性，就是我们思考性能优化的基本面。 那么，有哪些 Redis 基本特性需要我们考虑呢？Redis 的项目介绍中概括了它特性： Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported. 首先，Redis 使用操作系统提供的虚拟内存来存储数据。而且，这个操作系统一般就是指 Unix。Windows 上也能运行 Redis，但是需要特殊处理。如果你的操作系统使用交换空间，那么 Redis 的数据可能会被实际保存在硬盘上。关注公众号：程序员白楠楠，获取2020最新面试题 其次，Redis 支持持久化，可以把数据保存在硬盘上。很多时候

女主宣言 今天小编为大家分享linux io flush，通过本文你会清楚知道fsync()、fdatasync()、sync()、O_DIRECT、O_SYNC、REQ_PREFLUSH、REQ_FUA的区别和作用，希望能对大家有所帮助。 PS：丰富的一线技术、多元化的表现形式，尽在“360云计算”，点关注哦！ 1 fsync() fdatasync() sync()是什么？ 首先它们是系统调用。 1.1 fsync fsync(int fd) 系统调用把打开的文件描述符fd相关的所有缓冲元数据和数据都刷新到磁盘上（non-volatile storage）。 fsync() transfers ("flushes") all modified in-core data of (i.e., modified buffer cache pages for) the file referred to by the file descriptor fd to the disk device (or other permanent storage device) so that all changed information can be retrieved even after the system crashed or was rebooted. This includes

一、redis基础配置 １、进入redis界面：redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD ２、查看redis版本信息：进入客户端界面后，输入info ３、配置文件： networking配置 （1）bind 0.0.0.0：监听地址，可以用空格隔开后多个监听ip （2）protected-mode yes：保护模式 下图所示，保护模式打开时候，未设置监听地址或者未输入密码时候会有保护提升 关闭保护模式或者取消bind 0.0.0.0的注释，都可以正常使用redis （3）port 6379：默认监听端口更改处 （4）tcp-backlog 511：三次握手时候server端收到client的ack确认号之后的队列值 （5）timeout 0：客户端和redis服务的连接超时时间，默认是0，表示永不超时；此处客户端不是redis的client，是使用redis数据的java程序；若设置了时长，超时后再连接java程序会与redis重新三次握手；为防止不回收长连接造成数据库卡，建议设置时长 （6）tcp-keepalived 300：tcp会话保持时间，300s general配置 （7）daemonize　yes：是否在后台运行 （8）supervised no：UOS与CentOS7后都是用systemctl进行启动redis

一、持久化简介 Redis 的数据 全部存储 在 内存 中，如果 突然宕机 ，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制 ，它会将内存中的数据库状态 保存到磁盘 中。 持久化发生了什么 | 从内存到磁盘 我们来稍微考虑一下 Redis 作为一个 "内存数据库" 要做的关于持久化的事情。通常来说，从客户端发起请求开始，到服务器真实地写入磁盘，需要发生如下几件事情： 详细版 的文字描述大概就是下面这样： 客户端向数据库 发送写命令 (数据在客户端的内存中) 数据库 接收 到客户端的 写请求 (数据在服务器的内存中) 数据库 调用系统 API 将数据写入磁盘 (数据在内核缓冲区中) 操作系统将 写缓冲区 传输到 磁盘控控制器 (数据在磁盘缓存中) 操作系统的磁盘控制器将数据 写入实际的物理媒介 中 (数据在磁盘中) 注意: 上面的过程其实是 极度精简 的，在实际的操作系统中， 缓存 和 缓冲区 会比这 多得多 ... 如何尽可能保证持久化的安全 如果我们故障仅仅涉及到 软件层面 (该进程被管理员终止或程序崩溃) 并且没有接触到内核，那么在 上述步骤 3 成功返回之后，我们就认为成功了。即使进程崩溃，操作系统仍然会帮助我们把数据正确地写入磁盘。 如果我们考虑 停电/ 火灾 等 更具灾难性 的事情

1、RDB和AOF两种持久化机制的介绍 2、RDB持久化机制的优点 3、RDB持久化机制的缺点 4、AOF持久化机制的优点 5、AOF持久化机制的缺点 6、RDB和AOF到底该如何选择 我们已经知道对于一个企业级的redis架构来说，持久化是不可减少的 企业级redis集群架构：海量数据、高并发、高可用 持久化主要是做灾难恢复，数据恢复，也可以归类到高可用的一个环节里面去 比如你redis整个挂了，然后redis就不可用了，你要做的事情是让redis变得可用，尽快变得可用 重启redis，尽快让它对外提供服务，但是就像上一讲说，如果你没做数据备份，这个时候redis启动了，也不可用啊，数据都没了 很可能说，大量的请求过来，缓存全部无法命中，在redis里根本找不到数据，这个时候就死定了，缓存雪崩问题，所有请求，没有在redis命中，就会去mysql数据库这种数据源头中去找，一下子mysql承接高并发，然后就挂了 mysql挂掉，你都没法去找数据恢复到redis里面去，redis的数据从哪儿来？从mysql来。。。 具体的完整的缓存雪崩的场景，还有企业级的解决方案，到后面讲 如果你把redis的持久化做好，备份和恢复方案做到企业级的程度，那么即使你的redis故障了，也可以通过备份数据，快速恢复，一旦恢复立即对外提供服务 redis的持久化，跟高可用，是有关系的

# Redis configuration file example # Note on units: when memory size is needed, it is possible to specifiy # it in the usual form of 1k 5GB 4M and so forth: # # 1k => 1000 bytes # 1kb => 1024 bytes # 1m => 1000000 bytes # 1mb => 1024*1024 bytes # 1g => 1000000000 bytes # 1gb => 1024*1024*1024 bytes # # units are case insensitive so 1GB 1Gb 1gB are all the same. # By default Redis does not run as a daemon. Use 'yes' if you need it. # Note that Redis will write a pid file in /var/run/redis.pid when daemonized. daemonize yes # When running daemonized, Redis writes a pid file in /var/run/redis.pid

一、MySQL的主从复制 1.1 主从复制基本原理   MySQL的主从架构依赖于MySQL Binlog功能，Master节点上产生Binlog并且写入到文件中。   Master节点上启动一个DUMP线程：当Slave节点I/O线程连接Master时，Master创建这个线程，DUMP线程负责从Master的binlog文件读取记录，然后发送给Slave。每个连接到Master的Slave都有一个DUMP线程。   Slave节点上启动两个线程：IO线程和SQL线程，IO线程从MySQL上拉取Binlog日志并写入到本地的RelayLog日志；SQL线程不断从RelayLog日志中读取日志并解析执行，这样就可以保证所有在主服务器上执行过的SQL语句都在从服务器上一模一样的执行过一遍。 1.2 复制延迟   复制延迟，指的就是一个事务在Master执行完成以后，要多久以后才能在Slave上执行完成。   由于对Binlog文件以及RelayLog文件的读写均为顺序操作，在生产环境中，Slave上的IO线程对Binlog文件的Dump操作是很少产生延迟的。实际上，从MySQL5.5开始，MySQL官方提供了半同步复制插件，每个事务的Binlog需要保证传输到Slave写入RelayLog后才能提交，这种架构在主从之间提供了数据完整性

前言 IO 可以简单分为 磁盘 IO 和 网络 IO , 磁盘 IO 相对于 网络 IO 速度会快一点，本文主要介绍 磁盘 IO ， 网络 IO 下周写。 JAVA 对 NIO 抽象为 Channel , Channel 又可以分为 FileChannel （磁盘 io）和 SocketChannel （网络 io）。 如果你对 IO 的理解只是停留在 api 层面那是远远不够的，一定要了解 IO 在系统层面是怎么处理的。 本文内容： FileChannel 读写复制文件的用法。 ByteBuffer 的介绍 jvm 文件进程锁，FileLock HeapByteBuffer ，DirectByteBuffer 和 mmap 谁的速度更快 从 Linux 内核 中的 虚拟内存 、 系统调用 、 文件描述符 、 Inode 、 Page Cache 、 缺页异常 讲述整个 IO 的过程 jvm 堆外的 DirectByteBuffer 的内存怎么回收 <img src="http://oss.mflyyou.cn/blog/20200711165857.png?author=zhangpanqin" alt="image-20200711165857889" style="zoom: 33%;" /> 本文计算机系统相关的图全部来自 《深入理解计算机系统》 对 Linux