redis的lua

Redis在2.6之后增加了基于lua语言的解析模块,它允许用户端通过简单的lua语言实现简单的事务和逻辑运算。个人觉得对于一个Key-value服务器来说,这么做的确有些剑走偏锋的意思,但我相信在现实中确实有这样的需求。这些天,通过简单的脚本,测试了一下redis的lua脚本。

继续阅读“redis的lua”

推荐阅读:
众所周知redis的持久化有A
近一年来始终专注于No-SQL
碰到一个悲催的事情:一台Red

Redis的持久化存储——RDB

众所周知redis的持久化有AOF和RDB两种方式,其中AOF类似于操作日志的方式保存数据,即所有的数据都是基于现有的操作纪录进行优化保存,文件体积相对较大,但可读性较好,理论上可以通过管道直接导入redis。相对RDB格式的生成较为复杂,是将某一个时间节点上的内存镜像的优化映射。

继续阅读“Redis的持久化存储——RDB”

推荐阅读:
Redis在2.6之后增加了基
近一年来始终专注于No-SQL
碰到一个悲催的事情:一台Red

Key-Value式数据结构设计

近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。

之前从事的行业以企业管理和电子商务系统为主,这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项,特别是企业信息化管理系统和电子商务中的帐务结算子系统,这类系统对于数据的原子性和一致性的要求近乎苛刻,根据CAP原则,只能放弃性能作为代价。后来辗转到互联网行业,特别是SNS的开发和运维中,很多思维模式必须要打破。SNS,特别是Feed部分的数据结构,绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付,即便实现成功,也始终无法摆脱“硬撑”的嫌疑。

继续阅读“Key-Value式数据结构设计”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
碰到一个悲催的事情:一台Red

从Redis的数据丢失说起

碰到一个悲催的事情:一台Redis服务器,4核,16G内存且没有任何硬件上的问题。持续高压运行了大约3个月,保存了大约14G的数据,设置了比较完备的Save参数。而就是这台主机,在一次重起之后,丢失了大量的数据,14G的数据最终只恢复了几百兆而已。

正常情况下,像Redis这样定期回写磁盘的内存数据库,丢失几个数据也是在情理之中,可超过80%数据丢失率实在太离谱。排除了误操作的可能性之后,开始寻找原因。

继续阅读“从Redis的数据丢失说起”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL

Redis的主从复制

作为MySQL对于Web应用的优化之一,主从复制(Master-slaver)是普遍被接受的,Redis作为当下一个no-sql的解决方案,很自然的将这个特性引入。同时将“操作便捷”作为一大目标,Redis的主从复制更为简单,甚至不需要额外的操作,完全可以在两台热机之间进行。

继续阅读“Redis的主从复制”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL

用Nginx和Redis搭建琐碎文件下载站

对于网站来说,琐碎文件是一个很鸡肋的问题。太多过小文件的管理总有这样那样的问题,特别是当文件数量到达临界时,甚至作一条ls或者rm都无法正常反应。而且正常情况下琐碎文件都会主动缓存,花费太多资源去实现意义也不大。

之前曾经通过nginx的memcache扩展,配合TokyoTyrant Server(每次都觉得很别嘴)这个即支持memcache协议,又可以持久化的Key-Value实现过琐碎文件的管理,但限于Memcache无法逾越的1M鸿沟,只能保存些小文件。

继续阅读“用Nginx和Redis搭建琐碎文件下载站”

推荐阅读:
评价一个网站的“大小”,处于视
碰到这样一种情况:在使用新浪微
种种原因,站长已经很久没有关注

从SQL到NoSQL

之前接触到的基于LAMP平台的网站,凡是稍微有一点量上去的,在数据结构的设计上总是离不开“拆库拆表”。同样,作为网站的数据结构设计,很少会出现类似ERP系统才会应用到的函数(function)、存储过程(procudce)、触发器(trigger)什么的——曾经看过有ERP系统的所有逻辑都是通过这3者保存在数据库端的。加上MySQL本身的一些因素,用之前一个朋友的话说:“Mysql在网站中的地位更多的是一个数据容器,而不是完整意义上的数据库。”

继续阅读“从SQL到NoSQL”

推荐阅读:
Redis在2.6之后增加了基
众所周知redis的持久化有A
近一年来始终专注于No-SQL