博采众长,精于一技。Live for love, work for dream.

Redis的七把利器

长生剑、孔雀翎、碧玉刀、多情环、离别钩、霸王枪、拳头是古龙笔下的七种武器,而本文打算将Redis的几种使用方式 Strings、Hashs、Lists、Sets、Sorted Sets、Pub/Sub、Transactions 也比作七种武器,为大家讲解Redis的七种特性,并列举其适合的应用场景。

Strings
Strings 数据结构是简单的key-value类型,value其实不仅是String,也可以是数字。使用Strings类型,你可以完全实现目前 Memcached 的功能,并且效率更高。还可以享受Redis的定时持久化,操作日志及 Replication等功能。除了提供与 Memcached 一样的get、set、incr、decr 等操作外,Redis还提供了下面一些操作:

  • 获取字符串长度
  • 往字符串append内容
  • 设置和获取字符串的某一段内容
  • 设置及获取字符串的某一位(bit)
  • 批量设置一系列字符串的内容

Hashs
在Memcached中,我们经常将一些结构化的信息打包成hashmap,在客户端序列化后存储为一个字符串的值,比如用户的昵称、年龄、性别、积分等,这时候在需要修改其中某一项时,通常需要将所有值取出反序列化后,修改某一项的值,再序列化存储回去。这样不仅增大了开销,也不适用于一些可能并发操作的场合(比如两个并发的操作都需要修改积分)。而Redis的Hash结构可以使你像在数据库中Update一个属性一样只修改某一项属性值。

Lists
Lists 就是链表,相信略有数据结构知识的人都应该能理解其结构。使用Lists结构,我们可以轻松地实现最新消息排行等功能。Lists的另一个应用就是消息队列,可以利用Lists的PUSH操作,将任务存在Lists中,然后工作线程再用POP操作将任务取出进行执行。Redis还提供了操作Lists中某一段的api,你可以直接查询,删除Lists中某一段的元素。

Sets
Sets 就是一个集合,集合的概念就是一堆不重复值的组合。利用Redis提供的Sets数据结构,可以存储一些集合性的数据,比如在微博应用中,可以将一个用户所有的关注人存在一个集合中,将其所有粉丝存在一个集合。Redis还为集合提供了求交集、并集、差集等操作,可以非常方便的实现如共同关注、共同喜好、二度好友等功能,对上面的所有集合操作,你还可以使用不同的命令选择将结果返回给客户端还是存集到一个新的集合中。

Sorted Sets
和Sets相比,Sorted Sets增加了一个权重参数score,使得集合中的元素能够按score进行有序排列,比如一个存储全班同学成绩的Sorted Sets,其集合value可以是同学的学号,而score就可以是其考试得分,这样在数据插入集合的时候,就已经进行了天然的排序。另外还可以用Sorted Sets来做带权重的队列,比如普通消息的score为1,重要消息的score为2,然后工作线程可以选择按score的倒序来获取工作任务。让重要的任务优先执行。

Pub/Sub
Pub/Sub 从字面上理解就是发布(Publish)与订阅(Subscribe),在Redis中,你可以设定对某一个key值进行消息发布及消息订阅,当一个key值上进行了消息发布后,所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统,比如普通的即时聊天,群聊等功能。

Transactions
谁说NoSQL都不支持事务,虽然Redis的Transactions提供的并不是严格的ACID的事务(比如一串用EXEC提交执行的命令,在执行中服务器宕机,那么会有一部分命令执行了,剩下的没执行),但是这个Transactions还是提供了基本的命令打包执行的功能(在服务器不出问题的情况下,可以保证一连串的命令是顺序在一起执行的,中间有会有其它客户端命令插进来执行)。Redis还提供了一个Watch功能,你可以对一个key进行Watch,然后再执行Transactions,在这过程中,如果这个Watched的值进行了修改,那么这个Transactions会发现并拒绝执行。

相关阅读:Redis命令列表 - Redis命令参考中文版

原文地址:http://blog.nosqlfan.com/html/2942.html

如何选择最适合你的NoSQL数据库

当下NoSQL产品类型繁多,各有各的特点,再加上关系型数据库,貌似我们可选择的东西太多了。如诗言“乱花渐欲迷人眼”,在我们选择存储产品的时候,应该从哪些方面进行考量呢?下面一篇文章对当前的NoSQL产品进行了分类对比,列出了各家特点,有一定的指导意义。

NoSQL四大类


1.key-value存储


Examples Tokyo Cabinet/Tyrant, Redis, Voldemort, Oracle BDB
典型应用场景 内容缓存,主要用于处理大量数据的高访问负载,也用于一些日志系统等等。
数据模型 Key 指向 Value 的键值对,通常用hash table来实现
强项 查找速度快
弱项 数据无结构化,通常只被当作字符串或者二进制数据

2.列式数据库


Examples Cassandra, HBase, Riak
典型应用场景 分布式的文件系统
数据模型 以列簇式存储,将同一列数据存在一起
强项 查找速度快,可扩展性强,更容易进行分布式扩展
弱项 功能相对局限

3.文档型数据库


Examples CouchDB, MongoDB
典型应用场景 Web应用(与Key-Value类似,Value是结构化的,不同的是数据库能够了解Value的内容)
数据模型 Key-Value对应的键值对,Value为结构化数据
强项 数据结构要求不严格,表结构可变,不需要像关系型数据库一样需要预先定义表结构
弱项 查询性能不高,而且缺乏统一的查询语法。

4.图结构数据库


Examples Neo4J, InfoGrid, Infinite Graph
典型应用场景 社交网络,推荐系统等。专注于构建关系图谱
数据模型 图结构
强项 利用图结构相关算法。比如最短路径寻址,N度关系查找等
弱项 很多时候需要对整个图做计算才能得出需要的信息,而且这种结构不太好做分布式的集群方案。

原文地址:http://blog.monitis.com/index.php/2011/05/22/picking-the-right-nosql-database-tool/

多IDC数据分布南北互通解决方案

老冒:我朝Internet南北不畅通的解决方案(老旧方案)

该文章由于要翻墙才能看,所以就贴出来方便大家。

这个问题曾经花过不少力气,但也没有很理想解决。 正好建硕也要解决类似问题,我就把过去的土法给权当抛砖引玉写出来。4年前的东西了,想必现在会有更好的办法。

过去的方案:

1. DNS 采用geo load balance. 关键点在于获得南北的ip分布,并建立规则表。 很多公司应该有这个表
2. 所有的web前端都为 reverse proxy,当时采用SQUID,并设立了2级的级联cache
3. 数据库, application server 均中心化位于一个 data center.
4. 租用至少一个具有BGP路由的双线机房的主机,这台主机上跑着cache server (SQUID)
5. 配制web前端的cache规则,以实现最好的cache效果

application设计的时候考虑有多极cache服务器的存在,web app采用下面的原则:
1. 静态、不常变动内容永远采用最大的max-age, 更新的时候采用改变路径的方式来强制所有cache更新。e.g. http://yourserver/media/(version number)/... 每次升级改变version number.
2. 不常变化的动态内容给出可接受的max-age,根据性质归入几个group, e.g. 1天失效,1小时失效,5min失效。 web app永远要支持 请求中的cache control header,没有变化的时候给出304 Not Modified, 而不是给相同的内容.
3. 常变化的动态内容总是给一个足够短的max-age
4. 设计一个可以用来区别cache策略的cookie

cache server前端的策略
1. 前端cache server配制成利用cookie来简单判断该请求应该采用的策略:(1) max-age (2) check if modified (3) no cache
2. 用于级连的cache server忽略cookie规则

当时觉得级连的cache server最好自己专门实现,这样可以更智能地和app server交换些控制cache失效的策略(比如可以让app主动要求其失效一些符合规则的内容,这样它就可以永远cache所有内容,直到被主动失效,效率可以更好),但只是设计没有实现。

王建硕:关于两个机房的讨论
Tim:多IDC的数据分布设计(一)
多IDC的数据分布设计(二)

新版 PHP 中 MySQL 连接方式的改变

PHP5.3 和 PHP6 中,均采用了 mysqlnd 做为 mysql 数据库的默认驱动.
mysqlnd 是在 PHP 源码树中集成, 与原先的 libmysql 不同, mysqlnd 与内核联系更紧密.
官方说内存占用要节省 40% 左右.速度也更快.
顺便提一下.如果在升级到PHP5.3以后,数据库连接时出现
mysql_connect()[2002]  tcp://localhost:3306
的错误提示时.
需要将 localhost 改成 127.0.0.1,或者将连接方式由 tcp 改为 socket.
在使用 phpmyadmin 这类工具时,也可以按照上述方式修改 config.inc.php
来看看 mysqlnd 和 libmysql 对比
f7a3d07397226a95.png

原文地址:http://www.21andy.com/blog/20100308/1754.html

MySQL性能优化的最佳20+条经验

今天,数据库的操作越来越成为整个应用的性能瓶颈了,这点对于Web应用尤其明显。关于数据库的性能,这并不只是DBA才需要担心的事,而这更是我们程序员需要去关注的事情。当我们去设计数据库表结构,对操作数据库时(尤其是查表时的SQL语句),我们都需要注意数据操作的性能。这里,我们不会讲过多的SQL语句的优化,而只是针对MySQL这一Web应用最多的数据库。希望下面的这些优化技巧对你有用。

1. 为查询缓存优化你的查询

大多数的MySQL服务器都开启了查询缓存。这是提高性最有效的方法之一,而且这是被MySQL的数据库引擎处理的。当有很多相同的查询被执行了多次的时候,这些查询结果会被放到一个缓存中,这样,后续的相同的查询就不用操作表而直接访问缓存结果了。

这里最主要的问题是,对于程序员来说,这个事情是很容易被忽略的。因为,我们某些查询语句会让MySQL不使用缓存。请看下面的示例:

// 查询缓存不开启
$r = mysql_query("SELECT username FROM user WHERE signup_date >= CURDATE()");

// 开启查询缓存
$today = date("Y-m-d");
$r = mysql_query("SELECT username FROM user WHERE signup_date >= '$today'");

上面两条SQL语句的差别就是 CURDATE() ,MySQL的查询缓存对这个函数不起作用。所以,像 NOW() 和 RAND() 或是其它的诸如此类的SQL函数都不会开启查询缓存,因为这些函数的返回是会不定的易变的。所以,你所需要的就是用一个变量来代替MySQL的函数,从而开启缓存。

继续阅读 »

返回顶部