ChristmasLin
- 浏览: 42077 次
- 性别:
- 来自: 深圳
-
最新评论
-
kaungxiang：
新blog访问不了了
blog迁移，不再在此更新文章 -
v韧竹v：
有么有demo，给个吧谢啦，邮箱 xdj927@126.co ...
redis 多线程与阉割版 -
fei33423：
楼主的这个实现蛮难理解.下面这篇文章的里的实现CLH Lock ...
线程锁系列（1）：CLH Lock
文章列表
新blog: http://www.linyuzhi.com/ . 谢谢iteye提供的blog。
jdbm的架构比较清晰，分为2层，RecordManager和BTree/HTree。
底层的ReocrdManager封装了IO，事务，提供record的put_record，update_record，get_record，remove_record，commit_record，rollback_record等操作。
BTree和HTree相当于kv的索引层。提供通过key去定位对应的record的功能。
RecordManager也相当于一个kv store，不过它的key固定是一个long值，在put_record是由RecordManager生成。 ...
sdbm是 http://amisha.pragmaticdata.com/~schadow/dbm-java/ 上一个dbm的实现。sdbm主要由dir和page组成。它和w3c-dbm(见dbm之w3c-dbm)有所不同，w3c-dbm由dir和block组成。w3c-dbm的element保存时是区分索引和kv_content的，并且
kv_content 可以跨block w3c-dbm_block的，所以对kv的大小没限制。sdbm_page有点像hashmap的bucket，处理hash冲突时采用拉链法。因为sdbm_page是定长的，并且kv不能跨page，所以对于kv的大小限 ...
dbm是key-value store较常见的一种存储实现。http://en.wikipedia.org/wiki/Dbm dbm的各个实现。
http://aurora.regenstrief.org/~schadow/dbm-java/上有3个纯java的dbm实现。其中一个是W3C's
Jigsaw项目中抽离出来，后面出现的w3c-dbm都是指该项目。w3c-dbm实现比较简单，不支持事务。也不保证数据的完整和可靠。
w3c-dbm是一个hash表。先说几个概念：
1.block：w3c-dbm 把磁盘划分一系列block进行管理。block的大小在初 ...
memcached 对某些操作例如set，add支持noreply。也就是memcached 服务器不会对客户端进行应答。
假如在极短时间内，基于同一tcp connection（tcp_nodelay =false），进行2次操作，第1次是noreply，第2次need reply，并且2次的请求数据都非常小，会发生什么事呢？
下面基于java 客户端 xmemcached 1.3.5试一下，客户端和服务器分别部署在两台linux上。代码如下：
Java代码
redis 多线程与阉割版
- 博客分类：
- redis
终于折腾出redis的多线程版，大概实现：
1.每个db一个读写锁，dirty操作写锁，否则读锁。
2.一个boss线程，n个worker线程，boss线程负责accept连接，rehash，expire。wokrer负责处理客户端请求。client平均分配到各个worker上。一般的client请求都不会与其他client打交道，除了push遇到bpop，pubsub这两个操作。boss与worker的通信通过一对pipe，类似memcahced的处理方法。这个和java的selector的wakeup实现也有点类似，通过read pipe 来退出阻塞的epool。在 ...
redis的vm 设想
- 博客分类：
- redis
在抠redis时，对于vm的设计有一个初步的想法，把冷数据重新malloc到一系列的内存块中，系统swap的交换以4k为单位，在redis里，一般4k能容纳多个key或value，如果冷热数据在同一4k的块里，阻碍冷数据swap out.redis期望通过一种vm的机制，把冷数据swap out到文件里，需要时再从文件swap in。但是该机制的效果不理想，带来复杂度的同时也使系统运行不稳定。该机制已经不推荐使用，并可能在2.6废弃。
对于把冷数据remalloc到连续的内存块，抽象出来需要一个支持以下功能的模块：
1.管理一系列的内存块，块和块之间不必连续。但对外是透明的。
2. ...
最近在尝试把leveldb的移植到java上。对移植的leveldb测试写速度，测试场景分别用1,2,3,4同时并发压，每个线程写100w条数据。测试完成时间，结果是：1线程23s，2线程21s，3线程27s，4线程35s。1线程使用的时间出乎我的意料。一开始是怀疑在移植时，io的实现出问题，把写文件的操作屏蔽了，每个write操作到io那层都是马上返回。4个场景的完成时间都有所减少，但是1线程仍然和2线程耗时差不多。
先来看下leveldb的原生实现。leveldb是支持并发访问write的，在write的某些步骤（例如写log）用互斥锁来实现。每个write操作都会导致一次io调用。如 ...
ziplist和intset是redis的两种value格式。顾名思义，ziplist是压缩的list，intset是存放int的set。元素在里面都是被编成bytes。
ziplist的大概思路是如果存放的字符串可以被解析成int，则以int的编码保存，节省内存。编码成int时，head包含一个字节encoding，代表int的长度，分别是2bytes，4bytes，8bytes。具体的编码格式：
* |00pppppp| - 1 byte
* String value with length less than or equal to ...
redis的几项修改
- 博客分类：
- redis
最近的空闲时间都在抠redis的源码，强大并最大限度节约内存的数据类型是里面的亮点。
看完后有点想法，在上面做点个人感觉能起正向作用的修改。
基于redis的原生事件框架支持多线程处理访问，类似于memcached的处理手法。在多核处理器上能有多大的性能提升还要看测试结果。虽然说多线程访问引入锁和增加系统复杂度，但对于性能的提升还是抱乐观态度的。
额外提供2个数据类型，一个是ziplist的改进版，实现更紧凑的内存结构。一个是uintset，在某些场景，都是uint，uintset针对uint作优化，主要也是节省内存，但可能会损失轻微的性能。
移除vm的相关代码，虽然作 ...
服务端编程里，线程池的使用非常普遍。往往是按照逻辑划分为不同的线程池。这种做法存在一个问题，对每个线程池的利用都是局部的，缺少一个全局限制的目标。
希望能有一种任务池的机制，多个任务池共享一个线程池，每个任务池可配置并发执行的能力，主要有两个参数，固定为该任务池服务的线程数和峰值时可弹性增加的线程数。
在网上发现类似的两篇文章，放翁（文初）的《逻辑划分线程池》和淘宝博客上一篇《支持配额的共享线程池》。看了一下，对任务池（暂且都叫任务池）的看法都差不多，前者的“保留数”和后者“固定配额”都是固定分配给一个任务池的线程数。前者的“限制数”和后者的“弹性配额”是动态申请数。但是在 ...
这章来自3.3《Queues》。
这个framework的核心是排队阻塞线程。这里的排队限制为先进先出，因此，framework不支持基于优先级的排队。
对于同步队列使用非阻塞队列，从而不用构造一些low-level的锁这一个选择，几乎是没有争论的。有两个选择，
CLH Lock和MCS Lock。原始的CLH Lock仅仅使用自旋锁，但是相对于MSC Lock，它更容易处理cancel和timeout，所以选择了CLH Lock。最后设计出来的变种CLH Lock和原始的CLH Lock有较大的差别，需要描述一下。
...
这章来自3.1《Synchronization State》和3.2的《Blocking》。 AbstractQueuedSynchronizer会维护一个Int类型的synchronization state。公开了3个访问和更新state的方法，分别是：getState，setState和compareAndSetState。这些方法依赖java.util.concurrent.atomic ...
Doug Lea大神的concurrent包的lock，无论是在1.5还是1.6上（开或是不开自旋锁选项），都比jvm级别的synchronized高效和伸缩性更强，功能更丰富。对此很是好奇，语法上的实现是如何打败jvm级别上的实现？从Doug Lea的《The java.util.concurrent ...
之前的一个消息系统使用的底层存储是je，java版的bdb（berkeley db），先赞叹一下，这产品的确牛！相关的中文博客（http://www.bdbchina.com/）。但是对于消息系统的存储来说，它有一些特点，用je的btree有些不合适，然后出了问题只能等死或去调一大推不熟悉的源码，还有licence的问题。所以一直在考虑，在空闲时间，根据消息系统的特点写一个存储，msgStore，至少在排错方面不会那么被动。
首先，消息系统的几个特点：
消息的生命周期非常短，但又需要写文件，就怕那几乎不会出现的jvm崩溃。
插入和删除非常频繁，几乎没有更新，读取至多一次
外在表现像 ...