Browsed by
作者:stormzhange

It's my personal website on the web. But it's not only to write/show my own personal blog, it's also about internet, web technology, Java technology, front-end/back-end tech, and so on. BTW, thanks for your dropping by.
好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
95 views
好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
106 views
Understanding Java Garbage Collection Algorithms – Developers Journal

Understanding Java Garbage Collection Algorithms – Developers Journal

Java Garbage Collection Algorithms

Before diving into the practical implementation of details of the algorithms lets first understand what areGC Roots.

GC Roots

GC Roots are the objects which are accessible directly outside from the heap. Example:

  1. Active Threads.
  2. Static Variables.
  3. Local variable and input parameters of the currently executing methods
  4. JNI References.

来源: Understanding Java Garbage Collection Algorithms – Developers Journal

好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
103 views
好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
138 views
好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
142 views
The mythical 10x programmer 

The mythical 10x programmer 

A 10x programmer is, in the mythology of programming, a programmer that can do ten times the work of another normal programmer, where for normal programmer we can imagine one good at doing its work, but without the magical abilities of the 10x programmer. Actually to better characterize the “normal programmer” it is better to say that it represents the one having the average programming output, among the programmers that are professionals in this discipline.

The programming community is extremely polarized about the existence or not of such a beast: who says there is no such a thing as the 10x programmer, who says it actually does not just exist, but there are even 100x programmers if you know where to look for.

来源: The mythical 10x programmer –

好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
142 views
Redis Crashes

Redis Crashes

Anyway not every bit flipped is going to trigger a crash after all, because as somebody on stack overflow said:

“Most of the memory contains data, where the flip won’t be that visiblp”

The bytes representing ‘p’ and ‘e’ are not just 1 bit away, but I find the sentence to be fun anyway.

来源: Redis Crashes –

好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
99 views
好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
81 views
Redis源码学习-AOF数据持久化原理分析(0)

Redis源码学习-AOF数据持久化原理分析(0)

Redis作为一个使用广泛的KV内存存储,其也支持一定的数据持久化,这里试着介绍一下Redis在源码层面对持久化的实现机制。 总的来说,Redis支持的将其数据库里面的KV数据存储到磁盘,但可能会有短时间的丢失。官网关于持久化的介绍可以参考这里“Redis Persistence”,这篇文章介绍一下其在代码层面的实现。 其支持2中不同的持久化机制: 第一种RDB数据快照持久化。RDB持久化实际上就是对数据库内容做快照,然后将快照存储到磁盘上面,这样就要去我们进行周期性的做快照,但是这种方式无法做到实时的存储,出现故障时只能恢复上一次做快照时的状态,因此比较有限。不过redis的主从同步也是利用RDB实现的,这个我们后续文章分析; 第二种AOF日志实时持久化。AOF=Append Only File,也就是不断追加写的文件。在这种情况下,Redis首先将数据库做个快照,将数据还原为跟客户端的协议格式的文本数据,然后将其存储到一个临时文件中,然后将其覆盖成正常的aof文件,并把这个过程中新增的命令追加到aof文件后面,从此之后,后续的从客户端过来的命令都会不断根据不同的安全级别写到磁盘里面去。这样就支持了实时的持久化,只是可能会有短时间内的数据丢失,对一般系统还是可以容忍的。 下面一步步介绍其实现的原理。 0、数据初始化 当redis启动时,如果打开了aof开关,也就是配置了:”appendonly on”,那么就会从”appendfilename”指令指定的文件中加载数据库数据进行初始化;其调用流程为: main()->loadDataFromDisk(),后者会判断server.aof_state == REDIS_AOF_ON,如果是,就调用loadAppendOnlyFile函数去加载数据文件的数据,加载的方法就是把文件内容读出来当客户端请求一样调用各个命令的cmd->proc(fakeClient);还原数据,其实就是进行操作重放。 如果没有配置”appendonly on”,那么redis就会从RDB文件中加载数据。 /* Function called at startup to load RDB or AOF file in memory. */ void loadDataFromDisk(void) { long long start = ustime(); if (server.aof_state == REDIS_AOF_ON) { //如果AOF打开了,那么优先从AOF文件中加载数据,因为AOF文件的数据比RDB中的数据要新。 if (loadAppendOnlyFile(server.aof_filename) == REDIS_OK) redisLog(REDIS_NOTICE,”DB loaded from append only file: %.3f seconds”,(float)(ustime()-start)/1000000); } else { //否则就从RDB文件中加载数据。 if

来源: Redis源码学习-AOF数据持久化原理分析(0) | 趁着年轻

好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
89 views
Redis Slave进行数据备份BGSAVE时可能内存突发跑满

Redis Slave进行数据备份BGSAVE时可能内存突发跑满

前几天突然线上的redis slave 把64G的内存给占用满了,本来机器上的数据正常只会占用55.5%左右35G的内存的。 查看进程情况,当时redis正好在做BGSAVE操作,所以有2个Redis进程存在,初步怀疑是因为这个原因,但是理论上redis的BGSAVE是fork出来的进程,他们刚开始是共用物理内存的(Redis源码学习-AOF数据持久化原理分析(0)),除非主进程有数据修改,其实就是利用了操作系统的COW机制,巧妙的对redis做了一个数据快照。但明显线上系统不可能短时间内触发大部分数据的修改,所以排除这个的原因。 然后查看redis的日志发现了问题: 08 Apr 17:11:49 * MASTER SLAVE sync started //由于网络抖动,到master的连接断开,需要重连接 08 Apr 17:11:49 * Non blocking connect for SYNC fired the event. 08 Apr 17:28:23 * MASTER SLAVE sync: receiving 35120836844 bytes from master //开始去接收35G的数据到本地; 09 Apr 00:10:19 * 1 changes in 43200 seconds. Saving…

来源: Redis Slave进行数据备份BGSAVE时可能内存突发跑满 | 趁着年轻

好烂啊有点差凑合看看还不错很精彩 (No Ratings Yet)
Loading...
94 views
跳至工具栏