Redis介绍

REmoteDIctionaryServer(Redis) 是一个由SalvatoreSanfilippo写的key-value存储系统。

Redis是一个开源的使用ANSI C语言编写、遵守BSD协议、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

它通常被称为数据结构服务器，因为值（value）可以是字符串(String),哈希(Map),列表(list),集合(sets)和有序集合(sorted sets)等类型。主要采用内存存储：

 

BSD协议

简介

编辑

BSD协议全称

BSD是"BerkeleySoftware Distribution"的缩写，意思是"伯克利软件发行版"。显然，BSD这个名称并不是我们现在所理解的操作系统，而且其原意也并非简单的操作系统，而是一整套软件发行版的统称。从软件发行版到操作系统的演变是有历史过程的，这一点对FreeBSD很重要。

BSD协议身份

什么是许可协议呢，要介绍什么是许可，当你为你的产品签发许可，你是在让出自己的权利，不过，你仍然拥有版权和专利（如果申请了的话），许可的目的是，向使用你产品的人提供一定的权限。

不管产品是免费向公众分发，还是出售，制定一份许可协议非常有用，否则，对于前者，你相当于放弃了自己所有的权利，任何人都没有义务表明你的原始作者身份，对于后者，你将不得不花费比开发更多的精力用来逐个处理用户的授权问题。

而开源许可协议使这些事情变得简单，开发者很容易向一个项目贡献自己的代码，它还可以保护你原始作者的身份，使你至少获得认可，开源许可协议还可以阻止其它人将某个产品据为己有。以下是开源界的5大许可协议：五大开源许可协议分别是GPL,LGPL,BSD,MIT,Apache。

BSD就是这五种开源协议之一。

BSD协议BSD版本历史的演变

编辑

BSD协议出现

BSD的出现要追溯到上个世纪的七十年代，当加州大学伯克利分校的学生BillJoy在1971年完成了"BerkeleySoftware Distribution"的合并以后（包括Pascal系统和一个编辑器ex），就算是BSD诞生了第一个发行版，并且发行了大约三十份免费的系统拷贝。

BSD协议第二版

BSD的用户社团一直在不断扩大，到了1978年，软件发行版得到了更新和升级，结果产生了第二版的"BerkeleySoftware Distribution"，即2BSD，其中包括了增强的Pascal系统，vi和termcap（Unix用户一定会对vi和termcap这两个名词感到非常亲切）。2BSD的系统拷贝也是免费的，并且其最后一个版本2.11BSD至今还在世界的各个角落运行着。

BSD协议第三版

VAX计算机的普及导致了1979年末3BSD的诞生。3BSD是Berkely的第一个VAX发行版，同样也是Joy发布的，包含了C Shell和2BSD发行版中的大量附加程序，以及虚拟内存内核和标准32/V（Bell实验室的最后一个Unix版本，运行在VAX上）实用程序。

BSD协议第四版

到了1980年10月，Joy推出了一个焕然一新的发行版本，称为4BSD，其中包括Pascal编译器、Franz Lisp系统和邮件处理系统。4BSD支持DARPA网络，版权的控制是以大学为单位的，而不是以单台计算机为基础计算。

1980年，一个命名为CSRG（ComputerSystem Research Group，计算机系统研究小组）的小组被组建起来负责BSD的发行工作，并于1981年6月发行了称之为4.1BSD的新版本。请注意，不是5BSD。由于AT&T觉得5BSD会使用户将它和AT&TUnix System V相混淆，Berkely同意改变BSD将来版本的命名规则，将版本号仅保留在4BSD上，以后只增加4后面的小版本号。

4.2BSD于1983年8月正式发布，在18个月内就签发了1000多份站点许可证，是非常具有知名度的版本。到了1986年6月，4.3BSD发布，而到了1988年，CSRG发布了4.3BSD-Tahoe，这是第一个把BSD内核分解为依赖于机器和独立于机器的两部分的版本，这是非常有价值的，它使BSD得以移植到众多不同的体系结构中。

由于BSD使用了AT&TUnix的部分源代码，当AT&T源代码许可证费用不断增加的时候，一些希望能够使用BSD代码为PC生产基于TCP/IP联网产品的厂商要求Berkely将AT&T代码从BSD发行版中分离出来，并给他们签发单独的许可证条款，而不需要AT&T的源代码许可证。因此，到了1989年6月，一个完全没有AT&TUnix代码的BSD版本诞生了，称之为"NetworkingRelease 1"。这是第一套由Berkely发布的自由可再发行（freely-redistributable）的代码,，它允许被授权的用户以源代码或者二进制的形式发布修改过的或为修改过的代码，并且可以不向Berkely申报版税，唯一要求是在源代码文件中原封不动的保留Berkely的版权声明，并且在含有以上代码的其他产品文档中声明其产品包括来自于加州大学和其他贡献者的代码。这就是著名的BSD许可证的起源。

 

Key-Value数据库

http://www.oschina.net/question/7910_16600?sort=default&p=1#answers
http://singlelove1983.blog.163.com/blog/static/50849047200863122550370/

想要明白什么是key/value数据库，就必须了解哈希表（Hash Table）这种数据结构。
比如，Berkley DB就是典型的key/value数据库。

以下内容对哈希表进行了很形象的描述：
========================================
Google搜索到的头条：散列表（也叫哈希表），是根据关键码值直接进行访问的数据结构，也就是说，它通过把关键码值映射到表中一个位置来访问记录，以加快查找的速度。
这个映射函数叫做散列函数，存放记录的数组叫做散列表。

这个解释其实太含糊，想要整明白哈希表，那就得明白哈希表到底有什么样的优势。
数据结构中，有个时间算法复杂度O(n)的概念来衡量某种算法在时间效率上的优劣。
哈希表的理想算法复杂度为O(1)，也就是说利用哈希表查找某个值，系统所使用的时间在理想情况下为定值，这就是它的优势。
那么哈希表是如何做到这一点的呢？

我们定义一个很大的有序数组，想要得到位于该数组第n个位置的值，它的算法复杂度为O(1)。
哈希表利用哈希函数将需要存储的内容的关键值转换为这个有序数组中的某个值，在被存储内容和有序数组之间建立了映射关系。
这样，下次我们对这个值进行查找时只要使用同一个哈希函数对关键值进行转换，找到这个数组值就可以了。

如果还没有明白是怎么回事的话，那我们来举个例子。假设我们要做个存储结构，需要存储下来三国中的人物，以及他们的详细信息。
我们用他们的名字来作为存储的关键值，例如：刘备，曹操，孙权，关羽，张飞……等等。
这个时候我们如果想用一般的方法来查找这些英雄豪杰，需要遍历整个存储空间，如果这些英雄豪杰一共有n个，那么这时候的时间算法复杂度为O(n)。
显然如果n值很大，每次想要找到某个英雄就需要比较长的时间。

此时我们先定义一个大的有序结构数组HashValue[m]，用来存放各位英雄豪杰的信息。
然后编写一个哈希函数ChangeToHashValue (name)，函数的具体内容就不细说了，反正这个函数会将这些做为关键值的名字转换为HashValue[m]中的某个下标值x。
然后可以将英雄的信息放进HashValue[x]中去。这样，可以将所有英雄的信息存储起来。当查询的时候再使用哈希函数ChangeToHashValue(name)得到这个下标值，这样就很容易得到了这个英雄的信息。

例如：ChangeToHashValue(刘备)为10，那么就将刘备存储到HashValue [10]里面。
当查询的时候再次使用ChangeToHashValue(刘备)得到10，这个时候我们就可以很容易找到刘备的所有信息。
在实际应用中如果我们想把所有的英雄豪杰都存储进系统时，需要定义m>n。
就是数组的大小要大于需要存储的信息量，所以说哈希表是一个以空间换取时间的数据结构。

这个时候问题来了，出现了这种情况ChangeToHashValue(关羽)和ChangeToHashValue(张飞)得到的值是一样的，都是250，我们岂不是在存储过程中会遇到麻烦，怎么安排他们二位的地方呢（总不能让二位打一架，谁赢了谁呆在那吧），这就需要一个解决冲突的方法。
当遇到这种情况时我们可以这样处理，先存储好了关羽，当张飞进入系统时会发现关羽已经是250了，那咱就加一位，251得了，这不就解决了。
我们查找张飞的时候也是，一看250不是张飞，那就加个1，就找到了。
这时还存在一个问题，直接用ChangeToHashValue(赵云)为251，张飞已经早早占了他的地方，那就再加1存到252呗。
呵呵，这时我们会发现，当哈希函数冲突发生的机率很高时，可能会有一群英雄豪杰在250这个值后面扎堆排队。
要命的是查找的时候，时间算法复杂度早已不是O(1)了（所以我们说理想情况下哈希表的时间算法复杂度为O(1)）。

这就是说哈希函数的编写是哈希表的一个关键问题，会涉及到一个存储值在哈希表中的统计分布。
如果哈希函数已经定义好了，冲突的解决就成为了改变系统性能的关键因素。
其实还有很多种方法来解决冲突情况下的存储和查找问题，不一定非要线性向后排队，如果有好的哈希表冲突的解决方法也能很大程度上提高系统的效率。

 

一. Redis 优势

1.性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s。

2.丰富的数据类型 – Redis支持二进制案例的 Strings,Lists, Hashes, Sets 及 OrderedSets 数据类型操作。

3.原子 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。

4.丰富的特性 – Redis还支持publish/subscribe,通知, key过期等等特性。

二.使用场景(以网上商城来说)

1.商品基本信息（与库存分开）、商品分类是基本不变的，这些信息全部可以一次性加载到 redis中，作为只读信息，直接从redis中查询。或者不使用 redis，而是加数据库只读从库（MySQL中可以配置memcached作为数据缓存），从从库中读取数据。

2.用户登录信息（集中式session）

3.未登录的购物车信息（设置过期时间，key保存在客户端 cookie，取回的时候注意校验，防止攻击）

4.用户的收货地址、各种评论信息等等（登录时加载）

5.用户经常浏览的商品分类

6.聊天系统中

7.排行榜

8.其他的具体按照你的业务逻辑来