美食网站怎样做锅包肉软文代写新闻稿
今天还是挺开心的一天，又在工具箱里加了一个工具。嗯，但是快下班的时候也碰到一些不太顺心的事，让我有点恼火。我还真没想到一个专职的前端，加测试，以及其他一堆人，竟然不知道后端返回的markdown,在前端渲染成html展示后，如果字体太大，应该去改css这件事。
实在比较无语，还好有deepseek
反正我也纯粹技术直男那种气不过，突然灵光一闪，难道：
好吧，反正气也消了，冷静下来想想有啥要和老版沟通的要仔细，哈哈
言归正传，今天的一大收获是rocksdb agent。
大体是这么一回事,rocksdb是一个基于「硬盘」的kv数据库，因为前面做的伪实时服务是需要这么一个kv库来缓存结果的。最好的选择当然是redis，目前也是这么干的，还能直接设置一个ttl，很方便。
我自己的服务都喜欢把内存往大了整，再配机器肯定不会低于128G的，如果是霄龙，必须是256G+的。不过有时候生产上的服务器可能不一定能做主；另外还有一个点是，redis我定位不做持久化，所以在需要做程序持久化缓存的时候就得用别的库。目前我用mongo，其实也还不错，mongo的用途太多了。但mongo也有问题，如果真的用在生产上，大量零碎的并发还是烦人的。
我发现rocksdb刚好卡在这个空挡上，使用起来是类似下面这样的样子：
import rocksdb# 打开或创建一个 RocksDB 数据库
db = rocksdb.DB("test.db", rocksdb.Options(create_if_missing=True))# 插入数据
db.put(b"key1", b"value1")# 读取数据
value = db.get(b"key1")
print(value.decode('utf-8')) # 输出: value1# 删除数据
db.delete(b"key1")# 关闭数据库
del db
第一个小问题，读写是二进制字符串
然后我就像装一个环境来着，之前我以为rocksdb是像mysql那样，要专门起个服，后来发现是嵌入式的，类似sqlite的方式，只要pip就好了。
然后… pip失败了，报了一堆错我也没细看。后来按大模型的指导试了下，发现不管是mac还是ubuntu都挺不好装的，后来在我的某个镜像上装好了
conda install -c conda-forge python-rocksdb
第二个小问题，安装不方便
然后开始使用测试，突然发现在ipython里执行数据库导入时报错，原因是之前已经执行了一次了。原来rocksdb是进程锁的，一个进程只能开一个连接。这点上，多少有点像kafka>
第三个小问题，进程锁
因为这些问题，做一个agent就变得很有必要。总体上，这个agent按照json标准实现了普通读写和ttl读写，以及删除键。还有一些高级的功能就没有去搞了，这样就完成了我的持久化kv存储。
然后我又用一个对象稍微封装了一下，这样用起来比较方便。
wrock = WRock()# 写 2-6ms/条 在100和1000并发下测试 for 1000和10000keyword_args_list = [{'k':'test_var%s' % i , 'v': 123 * i , 'ttl' : 100, 'timeout':100} for i in range(1000)]tick1 = time.time()results = thread_concurrent_run(wrock.ttl_save, keyword_args_list= keyword_args_list, max_workers =100)print(time.time() - tick1)# 读 + 删 2-6ms/条keyword_args_list = [{'k':'test_var%s' % i , 'timeout':100} for i in range(1000)]tick1 = time.time()results = thread_concurrent_run(wrock.ttl_get, keyword_args_list= keyword_args_list, max_workers =100)print(time.time() - tick1)
总体上的效果还是让人满意的，每条大约是2ms-6ms的读写，有相当一部分会损耗在json序列化和反序列化上，但这也是必须的。
按2ms的速度估算，TPS大约是500。回头有空我也可以测一下redis，同样也受到json序列化的影响稍微降低了速度。
大约花了半天时间就完成好了这一切，感觉还是不错的。