- 博客(16)
- 收藏
- 关注
dbm之jdbm
jdbm的架构比较清晰,分为2层,RecordManager和BTree/HTree。 底层的ReocrdManager封装了IO,事务,提供record的put_record,update_record,get_record,remove_record,commit_record,rollback_record等操作。 BTree和HTree相当于kv的索引层。提供通...
2012-02-06 19:15:02
410
dbm之sdbm
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-db...
2012-02-02 21:48:09
417
dbm之w3c-dbm
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实...
2012-01-25 22:17:36
114
memcached noreply 和tcp Nagle
memcached 对某些操作例如set,add支持noreply。也就是memcached 服务器不会对客户端进行应答。 假如在极短时间内,基于同一tcp connection(tcp_nodelay =false),进行2次操作,第1次是noreply,第2次need reply,并且2次的请求数据都非常小,会发生什么事呢? 下面基于java 客户端 xmemcached 1....
2011-12-29 20:45:37
381
redis 多线程与阉割版
终于折腾出redis的多线程版,大概实现: 1.每个db一个读写锁,dirty操作写锁,否则读锁。 2.一个boss线程,n个worker线程,boss线程负责accept连接,rehash,expire。wokrer负责处理客户端请求。client平均分配到各个worker上。一般的client请求都不会与其他client打交道,除了push遇到bpop,pubsub这...
2011-12-15 22:51:40
152
redis的vm 设想
在抠redis时,对于vm的设计有一个初步的想法,把冷数据重新malloc到一系列的内存块中,系统swap的交换以4k为单位,在redis里,一般4k能容纳多个key或value,如果冷热数据在同一4k的块里,阻碍冷数据swap out.redis期望通过一种vm的机制,把冷数据swap out到文件里,需要时再从文件swap in。但是该机制的效果不理想,带来复杂度的同时也使系统运行不稳定。该...
2011-11-29 22:42:14
95
线程阻塞唤醒导致的效率问题
最近在尝试把leveldb的移植到java上。对移植的leveldb测试写速度,测试场景分别用1,2,3,4同时并发压,每个线程写100w条数据。测试完成时间,结果是:1线程23s,2线程21s,3线程27s,4线程35s。1线程使用的时间出乎我的意料。一开始是怀疑在移植时,io的实现出问题,把写文件的操作屏蔽了,每个write操作到io那层都是马上返回。4个场景的完成时间都有所减少,但是1线程...
2011-11-24 20:56:42
751
redis数据类型改进和补充:zip2list和uintset
ziplist和intset是redis的两种value格式。顾名思义,ziplist是压缩的list,intset是存放int的set。元素在里面都是被编成bytes。 ziplist的大概思路是如果存放的字符串可以被解析成int,则以int的编码保存,节省内存。编码成int时,head包含一个字节encoding,代表int的长度,分别是2bytes,4bytes,8byte...
2011-11-24 09:40:33
97
redis的几项修改
最近的空闲时间都在抠redis的源码,强大并最大限度节约内存的数据类型是里面的亮点。 看完后有点想法,在上面做点个人感觉能起正向作用的修改。 基于redis的原生事件框架支持多线程处理访问,类似于memcached的处理手法。在多核处理器上能有多大的性能提升还要看测试结果。虽然说多线程访问引入锁和增加系统复杂度,但对于性能的提升还是抱乐观态度的。 额外提供2个数据类型,一个...
2011-11-22 23:25:59
120
逻辑划分线程池-任务池
服务端编程里,线程池的使用非常普遍。往往是按照逻辑划分为不同的线程池。这种做法存在一个问题,对每个线程池的利用都是局部的,缺少一个全局限制的目标。 希望能有一种任务池的机制,多个任务池共享一个线程池,每个任务池可配置并发执行的能力,主要有两个参数,固定为该任务池服务的线程数和峰值时可弹性增加的线程数。 在网上发现类似的两篇文章,放翁(文初)的《逻辑划分线程池》和淘宝博客上一篇...
2011-05-22 10:44:59
305
Concurrent Synchronizer Framework(3)
这章来自3.3《Queues》。 这个framework的核心是排队阻塞线程。这里的排队限制为先进先出,因此,framework不支持基于优先级的排队。 对于同步队列使用非阻塞队列,从而不用构造一些low-level的锁这一个选择,几乎是没有争论的。有两个选择, CLH Lock和MCS Lock。原始的CLH Lock仅仅使用自旋锁,但是相...
2011-03-08 09:11:19
102
Concurrent Synchronizer Framework(2)
这章来自3.1《Synchronization State》和3.2的《Blocking》。 AbstractQueuedSynchronizer会维护一个Int类型的synchronization state。公开了3个访问和更新state的方法,分别是:getState,setState和compareAndSetState。这些方法依赖java.util.concurrent...
2011-03-03 23:14:28
105
Concurrent Synchronizer Framework(1)
Doug Lea大神的concurrent包的lock,无论是在1.5还是1.6上(开或是不开自旋锁选项),都比jvm级别的synchronized高效和伸缩性更强,功能更丰富。对此很是好奇,语法上的实现是如何打败jvm级别上的实现?从Doug Lea的《The java.util.concurrent Synchronizer Framework》开始,感兴趣的筒子们可下来拜读一下。 这个...
2011-01-14 12:16:49
114
消息存储系统
之前的一个消息系统使用的底层存储是je,java版的bdb(berkeley db),先赞叹一下,这产品的确牛!相关的中文博客(http://www.bdbchina.com/)。但是对于消息系统的存储来说,它有一些特点,用je的btree有些不合适,然后出了问题只能等死或去调一大推不熟悉的源码,还有licence的问题。所以一直在考虑,在空闲时间,根据消息系统的特点写一个存储,msgStore...
2011-01-08 00:26:29
135
线程锁系列(1):CLH Lock
最近在看关于线程锁的算法,做一个整理。资料出自于《The Art of Multiprocessor Programming》,算是一个读书笔记吧。示范代码基于java。 第一章是Craig, Landin, and Hagersten (CLH) locks。先上CLHLock的实现逻辑: public class CLHLock implements Lock { pr...
2010-12-30 23:22:46
190
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人