Posts Tagged Redis
Key-Value式数据结构设计
近一年来始终专注于No-SQL技术和大并发下的数据结构。整理一下思路。
之前从事的行业以企业管理和电子商务系统为主，这样的系统比较注重于对于数据的描述和事物化的流程管理。这样的模式自然是SQL的强项，特别是企业信息化管理系统和电子商务中的帐务结算子系统，这类系统对于数据的原子性和一致性的要求近乎苛刻，根据CAP原则，只能放弃性能作为代价。后来辗转到互联网行业，特别是SNS的开发和运维中，很多思维模式必须要打破。SNS，特别是Feed部分的数据结构，绝对是SQL模式的噩梦——Feed分发、个性化增删改加上分库分表的物理结构让传统上的SQLDB疲于应付，即便实现成功，也始终无法摆脱“硬撑”的嫌疑。
从Redis的数据丢失说起
碰到一个悲催的事情：一台Redis服务器，4核，16G内存且没有任何硬件上的问题。持续高压运行了大约3个月，保存了大约14G的数据，设置了比较完备的Save参数。而就是这台主机，在一次重起之后，丢失了大量的数据，14G的数据最终只恢复了几百兆而已。
正常情况下，像Redis这样定期回写磁盘的内存数据库，丢失几个数据也是在情理之中，可超过80%数据丢失率实在太离谱。排除了误操作的可能性之后，开始寻找原因。
Redis的主从复制
作为MySQL对于Web应用的优化之一，主从复制（Master-slaver）是普遍被接受的，Redis作为当下一个no-sql的解决方案，很自然的将这个特性引入。同时将“操作便捷”作为一大目标，Redis的主从复制更为简单，甚至不需要额外的操作，完全可以在两台热机之间进行。
用Nginx和Redis搭建琐碎文件下载站
对于网站来说，琐碎文件是一个很鸡肋的问题。太多过小文件的管理总有这样那样的问题，特别是当文件数量到达临界时，甚至作一条ls或者rm都无法正常反应。而且正常情况下琐碎文件都会主动缓存，花费太多资源去实现意义也不大。
之前曾经通过nginx的memcache扩展，配合TokyoTyrant Server（每次都觉得很别嘴）这个即支持memcache协议，又可以持久化的Key-Value实现过琐碎文件的管理，但限于Memcache无法逾越的1M鸿沟，只能保存些小文件。
从SQL到NoSQL
之前接触到的基于LAMP平台的网站，凡是稍微有一点量上去的，在数据结构的设计上总是离不开“拆库拆表”。同样，作为网站的数据结构设计，很少会出现类似ERP系统才会应用到的函数（function）、存储过程（procudce）、触发器（trigger）什么的——曾经看过有ERP系统的所有逻辑都是通过这3者保存在数据库端的。加上MySQL本身的一些因素，用之前一个朋友的话说：“Mysql在网站中的地位更多的是一个数据容器，而不是完整意义上的数据库。”
近期评论