fsync

3 月，跳不动了？>>> 多级缓存 文件数据的存取是计算机世界比较常见的需求，为提升文件存取效率，操作系统对于整个文件IO过程做了比较大的优化，多级缓存的思路在设计中无处不在。 用户操作数据到达磁盘存取流程如下： 黑色实线是用户态和内核态的分界线。 C语言开发的stdio库定义了文件操作相关的函数，stdio中实现的文件操作函数都有自己的stdio buffer，是在用户态实现的缓存。 如果用户操作读写都是较小size文件连续读写的话，stdio库可以将多次读写操作通过buffer进行缓冲与聚合之后统一处理，以提高程序运行效率。stdio库中的fflush函数可以主动的刷新buffer，主动调用底层操作系统进行buffer里面的数据更新。 操作系统调用read/write函数操作和磁盘之间也存在一层buffer，kernel buffer cache就是这层缓存。我们经常把linux中文件缓存称为page cache，设备纬度的缓存称为buffer cache。 page cache用于缓存文件内容，和文件系统相关，文件系统和磁盘建立映射，映射关系由文件系统维护 buffer cache用于缓存存储设备扇（块）区的数据，而不关心文件系统 总结来说，linux下的io操作，write/read函数调用是用户态和内核态之间的分界线

3 月，跳不动了？>>> Redis-3.2主从复制与集群搭建 一、Redis 主从搭建 1.下载并解压 1 2 3 4 5 6 7 8 yum install -y gcc gcc-c++ pcre zlib pcre-devel tcl wget http://download.redis.io/releases/redis-3.2.4.tar.gz tar -zxvf redis-3.2.4.tar.gz cd redis-3.2.4 make cd src && make test && make install mkdir /etc/redis cp ../redis.conf /etc/redis/redis.conf 2.优化参数 1 2 3 4 5 6 7 8 vim /etc/sysctl.conf net.core.somaxconn = 20480 #最大队列长度，应付突发的大并发连接请求，默认为128 net.ipv4.tcp_max_syn_backlog = 20480 #半连接队列长度，此值受限于内存大小，默认为1024 vm.overcommit_memory = 1 0 表示检查是否有足够的内存可用，如果是，允许分配；如果内存不够，拒绝该请求，并返回一个错误给应用程序。 1 允许分配超出物理内存加上交换内存的请求 2 内核总是返回true

3 月，跳不动了？>>> ##redis配置详解 # Redis configuration file example. # # Note that in order to read the configuration file, Redis must be # started with the file path as first argument: # # ./redis-server /path/to/redis.conf # Note on units: when memory size is needed, it is possible to specify # 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. ################################## INCLUDES ###########

3 月，跳不动了？>>> 如果投递出去的消息在网络传输过程中丢失，或者在RabbitMQ的内存中还没写入磁盘的时候宕机，都会导致生产端投递到MQ的数据丢失。 而且丢失之后，生产端自己还感知不到，同时还没办法来补救。 下面的图就展示了这个问题。 所以本文呢，我们就来逐步分析一下。 2 保证投递消息不丢失的confirm机制 其实要解决这个问题，相信大家看过之前的消费端ack机制之后，也都猜到了。 很简单，就是生产端（比如上图的订单服务）首先需要开启一个confirm模式，接着投递到MQ的消息，如果MQ一旦将消息持久化到磁盘之后，必须也要回传一个confirm消息给生产端。 这样的话，如果生产端的服务接收到了这个confirm消息，就知道是已经持久化到磁盘了。 否则如果没有接收到confirm消息，那么就说明这条消息半路可能丢失了，此时你就可以重新投递消息到MQ去，确保消息不要丢失。 而且一旦你开启了confirm模式之后，每次消息投递也同样是有一个delivery tag的，也是起到唯一标识一次消息投递的作用。 这样，MQ回传ack给生产端的时候，会带上这个delivery tag。你就知道具体对应着哪一次消息投递了，可以删除这条消息。 此外，如果RabbitMQ接收到一条消息之后，结果内部出错发现无法处理这条消息，那么他会回传一个nack消息给生产端

3 月，跳不动了？>>> 前些日子，监控显示线上偶尔发生请求两秒超时的情况。解决这个问题前前后后花了不少时间，也走了一些弯路。这里记录下来备忘。 前期分析 首先需要了解一下我们的服务： 我们的服务是一组无状态的前端服务器加上有状态的后端存储层。 这些服务都部署在腾讯云黑石服务器上面。 第一件事是要定位问题出现在前端还是后端。通过日志，我们发现在出错时间段里，每个前端服务器都有报错，并且出错请求都是发往同一后端服务器的。由此可见，问题出现在后端服务上。 接下来，需要分析出错的特征。通过日志发现错误都是因为前端两秒超时导致，而后端在前端超时之后事实上是完成了请求。因为是存储服务，我们自然在第一时间就查看了磁盘的情况。果然，在出错时，磁盘的 io.util 非常高( sar -dp 的输出，从第4列开始分别是 tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util )： 需要注意的是： io.util非常高，且只持续了2~3秒 几乎所有盘的io.util都高 io的tps和吞吐并不高 另外，还发现了另外一个规律：单台机器，大概每12小时左右会出现io.util高，并伴随着超时出错： 问题排查 快速排查 我们做了一些快速排查，试图以比较小的代价找到问题的根源： 查看系统的定时任务 查看系统日志 查看存储服务代码中的定时任务 可惜

某厂面试归来，发现自己落伍了！>>> 一、持久化 　　所谓的持久化就是把内存中的数据写到磁盘中去，防止服务宕机后内存数据丢失。Redis4.0之前提供了两种持久化方式:RDB（默认） 和AOF，Redis4.x之后新增了一种混合持久化（本文所用的Redis版本是 redis‐5.0.2 ） 　　1、RDB 　　RDB是Redis Database缩写，在默认情况下，Redis将内存数据库快照保存在名字为dump.rdb的二进制文件中。可以对Redis进行设置，让它在 “ N秒内至少有M个键值改动 ” 这一条件被满足时，自动保存一次数据。比如下图，900秒内有1个键值或者300秒内有10个键值或者60秒内有10000个键值改动，自动保存一次数据；关闭RDB只需要将所有的save保存策略注释掉即可。 　　还可以手动执行命令生成RDB快照，进入Redis客户端执行命令save或bgsave可以生成dump.rdb文件，每次命令执行都会将所有Redis内存快照到一个新的rdb文件里，并覆盖原有rdb快照文件。save是同步命令，bgsave是异步命令，bgsave会从redis主进程fork（fork()是linux函数）出一个子进程专门用来生成rdb快照文件。Redis配置自动生成rdb文件后台使用的是bgsave方式。 save与bgsave对比 命令 save bgsave IO类型

1、index API IndexRequest request = new IndexRequest( "posts", //index "doc", //type 类型，我对类型的理解有点类似于数据库中的表 index类似于数据库中的database "1"); //Document Id String jsonString = "{" + "\"user\":\"kimchy\"," + "\"postDate\":\"2013-01-30\"," + "\"message\":\"trying out Elasticsearch\"" + "}"; request.source(jsonString, XContentType.JSON); //source可以有多种形式下面介绍 source可以以map的形式提供，查看官方文档介绍map形式提供的source会自动转换成json格式，初步观察源代码，写的还挺复杂，简单过了一遍其实没太懂，大概意思是map->XContentBuilder，XContentBuilder通过内置工具生成json Map<String, Object> jsonMap = new HashMap<>(); jsonMap.put("user", "kimchy"); jsonMap.put("postDate", new Date());

1. Index Setting（索引设置） 每个索引都可以设置索引级别。可选值有： static ：只能在索引创建的时候，或者在一个关闭的索引上设置 dynamic ：可以动态设置 1.1. Static index settings（静态索引设置） index.number_of_shards ：一个索引应该有的主分片（primary shards）数。默认是5。而且，只能在索引创建的时候设置。（注意，每个索引的主分片数不能超过1024。当然，这个设置也是可以改的，通过在集群的每个节点机器上设置系统属性来更改，例如：export ES_JAVA_OPTS="-Des.index.max_number_of_shards=128"） index.shard.check_on_startup ：分片在打开前是否要检查是否有坏损。默认是false。 index.routing_partition_size ：自定义的路由值可以路由到的分片数。默认是1。 1.2. Dynamic index settings（动态索引设置） 如果想学习Java工程化、高性能及分布式、深入浅出。微服务、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级交流：854630135，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家。 index.number

从存储上来讲所有的监控指标metric都是相同的，但是在不同的场景下这些metric又有一些细微的差异。 例如，在Node Exporter返回的样本中指标node_load1反应的是当前系统的负载状态，随着时间的变化这个指标返回的样本数据是在不断变化的。而指标node_cpu所获取到的样本数据却不同，它是一个持续增大的值，因为其反应的是CPU的累积使用时间，从理论上讲只要系统不关机，这个值是会无限变大的。 为了能够帮助用户理解和区分这些不同监控指标之间的差异，Prometheus定义了4中不同的指标类型(metric type)：Counter（计数器）、Gauge（仪表盘）、Histogram（直方图）、Summary（摘要）。 在Exporter返回的样本数据中，其注释中也包含了该样本的类型。例如： # HELP node_cpu Seconds the cpus spent in each mode. # TYPE node_cpu counter node_cpu{cpu="cpu0",mode="idle"} 362812.7890625 Counter：只增不减的计数器 Counter类型的指标其工作方式和计数器一样，只增不减（除非系统发生重置）。常见的监控指标，如http_requests_total，node_cpu都是Counter类型的监控指标。

prometheus的客户端与服务端 客户端是提供监控指标数据的一端（如写的exporter）。prometheus提供了各种语言的客户端库，需要通过Prometheus客户端库把监控的代码放在被监控的服务代码中。当Prometheus获取客户端的HTTP端点时，客户端库发送所有跟踪的度量指标数据到服务器上。详情见客户库 服务端是指prometheus server，拉取、存储和查询各种各种指标数据。 histogram histogram是柱状图，在Prometheus系统中的查询语言中，有三种作用： 对每个采样点进行统计（并不是一段时间的统计），打到各个桶(bucket)中 对每个采样点值累计和(sum) 对采样点的次数累计和(count) 度量指标名称: [basename]的柱状图, 上面三类的作用度量指标名称 [basename]_bucket{le=“上边界”}, 这个值为小于等于上边界的所有采样点数量 [basename]_sum [basename]_count histogram例子 如上表，设置bucket=[1,5,10]，当实际采样数据如是采样点所示, Observe表示采样点落在该bucket中的数量，即落在[-,1]的样点数为2，即落在[1,5]的样点数为3，即落在[5,10]的样点数为1，write是得到的最终结果