分布式事务内存数据库--MemDB

高性能和可伸缩

架构

图片说明

特点

MemDB 是一个key/value平台系统。
MemDB定位于【memcache、redis】与【mysql】间的一个key/value持久存储平台。
如下特点:

  1. MemDB是定位于【memcache、redis】与【mysql】间的一个key/value持久存储平台。
  2. 与Memcache、redis不同,MemDB通过扩充存储引擎满足不同类型数据、业务规则的数据的高效存储于操作。
  3. 对于不同的引擎,Unistor对外提供一致的访问API。但存储引擎可以通过MemDB API的扩展字段,对接口进行裁剪、扩展,以满足自己业务的需要。
  4. MemDB虽自身不支持分组,但用户可以基于Key的范围进行划分(也可基于hash)。系统对基于key范围的数据导出提供支持。key的大小比较及hash,有用户的存储引擎决定
  5. MemDB通过zookeeper实现集群以保证系统的高可用。一个集群对外不分主、从内部进行消息的转发。支持用户建立master、slave集群。
  6. MemDB提供可配置的Read、write Cache以保证读写的高效。
  7. MemDB有自己的binlog,保证系统数据的高可靠,而且数据同步采用多连接防止阻塞。支持高效的跨IDC数据同步。
  8. MemDB提供完备的运行信息共运维使用。此信息可通过监控端口的mc stats指令获取,也可以通过get/gets接口获取,此时i参数的值为2(获取系统信息)。
  9. MemDB提供统一的运维工具。
  10. MemDB的存储引擎开发非常简单。

配置文件

[common]
home=/usr/local/memdb #运行目录
thread_num=4 #线程数量
store_type=bdb #存储engine类型
sock_buf_kbyte=8192 #数据同步的socket buf
max_chunk_kbyte=1024 #数据同步最大的chunk大小
store_flush_num=10000 #多少条数据必须sync 存储
host=172.168.1.8 #主机标示,为内部同步的host ip地址
idc=yf #所属的idc名字
group=1 #所属的分组名字
trans_conn_num=20 #内部消息转发的连接数量
sync_conn_num=20 #内部数据同步的连接树立
write_cache_mbyte=256 #写cache的大小
read_cache_mbyte=2048 #读cache的大
read_cache_max_key_num=20000000 #读cache的最大key数量
master_lost_binlog=100000 #slave变为master,运行丢失的最大binlog数量。
max_write_queue_messge=500000 #写队列排队消息的最大数量,超过则写失败。
max_trans_message=100000 #并发master转发消息的最大数量,超过则失败。
monitor=:9900 #监控端口
enable_expire=yes/no #是否支持key的expire,yes:支持;no:不支持。
expire_default=3600 #若没有指定expire,缺省的expire值,单位为s。
expire_concurrent = 100 #expire检查的并发消息数量。

[inner_dispatch]
user=async #内部分发的连接用户名
passwd=async_passwd #内部分发的用户口令
listen=:9903 #内部分发的监听地址

[outer_dispatch]
user=async #外部分发的连接用户名
passwd=async_passwd #外部分发的用户口令
listen=:9903 #外部分发的监听地址

[zk]
server=172.16.42.1:2181 #zookeeper的连接
auth= #zk的认证
root=/memdb #zookeeper配置信息的root目录

[binlog]
path=/data2/kv_data/data/binlog #binlog文件的路径
file_prefix=binlog #binlog文件的前缀
file_max_mbyte=1024 #binlog文件的最大大小
max_file_num=24 #维护的binlog文件的数量
del_out_file=yes #是否删除不维护的binlong文件
cache=no #对接受的到binlog是否cache,cache的话,若程序以外down会丢失
flush_log_num=100000 #多少条日志flush binlog文件
flush_log_second=100 #多少秒必须flsuh binlog文件

[bdb] #bdb存储engine的配置
env_home=/data3/bdb_home #bdb的env home目录
db_path=/data4/bdb_data #bdb的db目录
compress=yes #bdb是否压缩
cache_msize=3000 #bdb的cache大小
page_ksize=32 #bdb的page大小
[bdbc] #海量、高效、动态可配多计数值的计数器引擎配置
env_home=/data3/bdb_home #bdb的env home目录
db_path=/data4/bdb_data #bdb的db目录
compress=yes #bdb是否压缩
cache_msize=3000 #bdb的cache大小
page_ksize=32 #bdb的page大小
key_type=int64 #key的类型。可为int32/int64/int128/int256/char
int32_hex=no/yes #对于int32的key,返回时是否以16进制表示
int64_hex=yes/no #对于int64的key,返回时是否以16进制表示
hex_upper=yes/no #对于返回的16进制的key,是否大写a-f
group_start_time_bit =0 #bdb文件分组的key的group bit32值的开始bit位
group_end_time_bit=5 #bdb文件分组的key的group bit32值的结束bit位
counter_def_file=/usr/home//unistor/bin/counter_def.dat #key的计数器名字配置文件

Mdbgoose:

var memdb = require('memdb-client');
var P = memdb.Promise;
var mdbgoose = memdb.goose;
// Define player schema
var playerSchema = new mdbgoose.Schema({
    _id : String,
    name : String,
    areaId : Number,
    deviceType : Number,
    deviceId : String,
    items : [mdbgoose.SchemaTypes.Mixed],
}, {collection : 'player'});
// Define player model
var Player = mdbgoose.model('player', playerSchema);
var main = P.coroutine(function*(){
    // Connect to memdb
    yield mdbgoose.connectAsync({
        shards : { // specify all shards here
            s1 : {host : '127.0.0.1', port: 31017},
            s2 : {host : '127.0.0.1', port: 31018},
        }
    });
    // Make a transaction in s1
    yield mdbgoose.transactionAsync(P.coroutine(function*(){
        var player = new Player({
            _id : 'p1',
            name: 'rain',
            areaId : 1,
            deviceType : 1,
            deviceId : 'id1',
            items : [],
        });
        // insert a player
        yield player.saveAsync();
        // find player by id
        var doc = yield Player.findByIdAsync('p1');
        console.log('%j', doc);
        // find player by areaId, return array of players
        var docs = yield Player.findAsync({areaId : 1});
        console.log('%j', docs);
        // find player by deviceType and deviceId
        player = yield Player.findOneAsync({deviceType : 1, deviceId : 'id1'});
        // update player
        player.areaId = 2;
        yield player.saveAsync();
        // remove the player
        yield player.removeAsync();
    }), 's1');
});
if (require.main === module) {
    main().finally(process.exit);
}
#学习路径#
全部评论

相关推荐

04-11 00:51
已编辑
门头沟学院 Java
先说一下楼主的情况:双非本大三,两段实习,javaer,想要找一个暑期大厂offer,努力了两个月,三月份每天的状态就是算法,八股,项目,四月份更是一个面试没有,最终还是没有结果,心碎了一地。期间面了一些中小厂,大厂只有腾讯约面,其他大厂都投了一遍,但是还是石沉大海。再看一下楼主的面试结果吧,就不说ttl了腾讯s3:三面挂csig:一面挂teg:三面挂wxg:一面挂没错,面了八次腾讯,两次三面挂,当时真的心都碎了。其他中小厂都有面,有的没过,有的oc,但是都没有去。其他大厂投了简历,但是不是简历挂,就是测评挂,都说今年行情好很多,各大厂都扩招,可是问题出在那里呢?学历背景吗?实习经历吗?还是简历不够好看?依稀记得,从年初七就离开了家里,回到学校,早早准备面试,当时自己认为凭借着自己的两段实习经历,以及大二就开始准备的八股算法,拿大厂offer不是问题,但是还是不敢放松,回校的状态每天就是算法,八股,还有查看各种招聘信息,想着尽早投机会多,但是事实证明,投的早,不如投的刚刚好。当时想着,先投一些中小厂开始面试,找找面试感觉,从2.10就开始有面试了,基本都是线下面试,面试的感觉都很不错,觉得自己的状态慢慢回来了,期间也有oc一些中小厂,但是自己的目标并不在此,只是想练一下手,遂拒。后面投了腾讯的暑期实习基地,不久就约面了,第一次面这么大的厂,多少有点紧张,好在运气还不错,遇到的面试官也比较好,一直干到了三面,期间看牛客有不少说一面就挂了的,感觉自己还是比较幸运的,但是没想到倒在了三面,一周后就挂了,伤心是有的,但是想到这才刚刚开始,还有很多机会,便继续准备下一次面试了,很快,被另外一个部门捞了,一进会议,面试官没开摄像头,看网上说没开摄像头很多都是kpi,但是自己给自己打气,认为面试官只是不方便开摄像头罢了,面完,感觉良好,没问什么很难得问题,基本都答出来了,算法两道也a了一道,感觉实习不会这么严格吧?还是过了一会挂了,因为这个?还是技术不太匹配?面试过程中说搞C++的,心想,搞c++的你面我干啥?唉,这时候有点气馁,然后就接下来半个月没有面试。这时已经是三月底了,看到牛客好多人都已经陆陆续续拿到了offer,看人家的面试准备也没那么早,有0实习的,有没刷算法的,有两个面的,,,唉,反正是一言难尽啊,感觉努力没有什么意义,面试多半是看面试官的感觉,主观性很大啊,只要你技术没有太大的问题。第三次面试腾讯,面试来的比较突然,期间已经有几天没看八股什么的了,临时看了一下之前自己做的面试笔记,但是面试却异常顺利,三天闯到了三面,自己也不敢相信,三面玩感觉也良好,脑子里不得不想着一些“offer结算画面”,但是过了一会查看流程显示“流程终止”,我?哎,当时真的有苦说不出啊,也是一晚没睡。后面就逐渐开始褪去大厂梦了,看着曾经跟自己交流的牛油,朋友,认识的人,觉得他们技术不太如你,算法刷的没你多,进了大厂,但是这又如何呢?能力强不强不是你了说了,面试官说了算。也逐渐知道,不是你能力好就可以了,还得有运气,运气,运气。这个过程太累了,和自己和解吧,不用非得大厂,找个合适一点的就好,放轻松一点。今天有点心事睡不着,闲着想写一些自己的面试过程,勿喷。附上一张面试的情况,公司就不方便透露了。
怒卷的斯科特:八分运气两分实力
点赞 评论 收藏
分享
评论
点赞
收藏
分享

创作者周榜

更多
牛客网
牛客网在线编程
牛客网题解
牛客企业服务