log日志文件-leveldb源码剖析(4)

往leveldb写一个KV对时先写log,再写MemTable,这样完成一次写入,写log是追加顺序写文件,写MemTable是跳表插入写内存,随机写转化成顺序写,只涉及一次磁盘IO及一次内存写,因此leveldb写入速度非常快。先写log也是为防止发生如进程挂掉时,MemTable的数据仍然可以从log进行重建恢复,不会造成数据丢失。
阅读全文

Arena内存管理-leveldb源码剖析(1)

leveldb实现了定制的Arena内存分配器,并没有直接使用glibc的malloc或者c++标准库的new,Arena主要与MemTable关联使用,实际主要用于SkipList中的Node内存分配,统一MemTable的内存分配需求,减少内存分配的实际系统调用次数(尤其针对小块内存),减少内存分配中的空洞(碎片),但也会造成一定的内存浪费;统一内存释放,不必频繁new/delete;鉴于Arena在leveldb中的使用场景不需考虑线程安全。Arena的实现简单轻量,代码总计百余行,服务于leveldb的定制需求,提高应用性能,并且提供了内存对齐的版本。
阅读全文

关于Redis RDB 持久化认知的一个误区

众所周知,redis RDB持久化主要有两种方式:save和bgsave,其触发方式包括自动和手动。bgsave不论在何种触发方式下均通过后台进程的形式进行,对主线程阻塞相对很短,生产环境下推荐使用;而save命令会阻塞主线程直到持久化完成,生产环境下一般禁止使用。而在redis服务的redis.conf配置文件中,有关于RDB持久化,是通过“save <seconds> <changes>”的形式进行配置,问题来了,这个save是对应的save命令还是bgsave命令?这种配置形式是不是可能让人产生误解?
阅读全文

thrift 序列化字段读写的一个小坑

前段时间跟同事一块联调某系统时,client发送thrift序列化后的数据,本地打log能正确读到该字段,而server却收不到该字段的值,感到比较诡异,通过修改下读写的方法就ok了,花了一点时间踩了一个小坑,先从业务代码片段,再到源码分析,最后再与protobuf作对应点的简单比较,与大家分享下。
阅读全文

Java NIO SocketChannel write与DirectByteBuffer实现分析

系统部同事反映了一个问题,在Cassandra内部场景中使用了NIO通信,并使用了one client one thread模型,且不说这种通信模型的问题,同事反映每当有较大的数据传输时都会有很大的内存增长,看似内存泄露,其实这部分内存并不是jvm堆内存,实际叫堆外内存,不容易回收,下面我们先来分析为什么会有内存的不断增长,然后再给出一个比较好的解决方案。
阅读全文