blogjava-凯发k8网页登录

操作系统:centos6.3
tomcat:7.0.42
jdk:1.6.0_45
配置:8g,4核.

最近tomcat负载比较高,默认的配置和bio的处理方式已经无力支撑.据说apr能提升50%~60%的性能,所以尝试下apr优化.
apr介绍:

tomcat可以使用apr来提供超强的可伸缩性和性能，更好地集成本地服务器技术。  apr(apache portable runtime)是一个高可移植库，它是apache http server 2.x的核心。  apr有很多用途，包括访问高级io功能(例如sendfile,epoll和openssl)，os级别功能(随机数生成，系统状态等等)，本地进程管理(共享内存，nt管道和unix sockets)。这些功能可以使tomcat作为一个通常的前台web服务器，能更好地和其它本地web技术集成，总体上让java更有效率作为一个高性能web服务器平台而不是简单作为后台容器。  在产品环境中，特别是直接使用tomcat做web服务器的时候，应该使用tomcat native来提高其性能。

1. 服务器安装gcc

客户服务器连不上外网,服务器也没有gcc,所以先使用代理连接外网,修改/etc/yum.conf,加入代理配置:

proxy=http://10.103.0.46:808

如果需要验证加入用户名密码:

proxy_username=代理服务器用户名 proxy_password=代理服务器密码 

yum使用163的centos源:参考
先备份

mv /etc/yum.repos.d/centos-base.repo /etc/yum.repos.d/centos-base.repo.backup 

然后下载 放入到/etc/yum.repos.d/(操作前请做好相应备份)

运行以下命令生成缓存:

yum clean all yum makecache 

然后安装gcc:

yum -y install gcc 

2. 安装apr

从下载apr,apr-util,apr-iconv. 因为服务器没有配置全局的http代理,只是yum代理,所以下载之后传到服务器即可.

传输完安装apr:

tar zxvf apr-1.5.1.tar.gz cd apr-1.5.1 ./configure --prefix=/usr/local/apr make make install 

安装apr-iconv:

tar zxvf apr-iconv-1.2.1.tar.gz cd apr-iconv-1.2.1 ./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr make make install 

安装apr-util:

tar zxvf apr-util-1.5.3.tar.gz cd apr-util-1.5.3 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv make   make install 

安装tomcat-native:首先到tomcat/bin目录下,找到对应的tar文件.

tar zxvf tomcat-native.tar.gz cd tomcat-native-1.1.27-src/jni/native/ ./configure --with-apr=/usr/local/apr --with-java-home=/usr/lib/jdk1.6.0_45 make make install 

安装完成之后 会出现如下提示信息

libraries have been installed in: /usr/local/apr/lib 

添加环境变量: vi /etc/profile在文件末尾处添加下面的变量

export ld_library_path=/usr/local/apr/lib 

然后执行下面命令，使环境变量即时生效

source /etc/profile 

以下为完整安装脚本:

#setup apr tar zxvf apr-1.5.1.tar.gz cd apr-1.5.1 ./configure --prefix=/usr/local/apr make && make install cd ../ #setup apr-iconv tar zxvf apr-iconv-1.2.1.tar.gz cd apr-iconv-1.2.1/ ./configure --prefix=/usr/local/apr-iconv --with-apr=/usr/local/apr make && make install cd ../ #setup apr-util tar zxvf apr-util-1.5.3.tar.gz cd apr-util-1.5.3 ./configure --prefix=/usr/local/apr-util --with-apr=/usr/local/apr --with-apr-iconv=/usr/local/apr-iconv/bin/apriconv make && make install #setup tomcat-native cd /app/apache-tomcat-7.0.42/bin tar zxvf tomcat-native.tar.gz cd tomcat-native-1.1.27-src/jni/native ./configure --with-apr=/usr/local/apr --with-java-home=/usr/lib/jdk1.6.0_45 make && make install cd / #ld_library_path echo -e 'export ld_library_path=/usr/local/apr/lib' >> /etc/profile export ld_library_path=/usr/local/apr/lib source /etc/profile 

3. 配置tomcat

修改tomcat配置conf/server.xml:

      name="tomcatthreadpool" nameprefix="catalina-exec-"         maxthreads="800" minsparethreads="400"/>              port="80" executor="tomcatthreadpool" protocol="org.apache.coyote.http11.http11aprprotocol"                connectiontimeout="20000"                redirectport="8443" enablelookups="false" acceptcount="1000"/> 

修改为http11aprprotocol 协议.

之后启动tomcat即可.

遇到问题:

severe: failed to initialize the sslengine. org.apache.tomcat.jni.error: 70023: this function has not been implemented on this platform 

请关闭ssl侦听，除非你有使用ssl,修改conf/server.xml

 classname="org.apache.catalina.core.aprlifecyclelistener" sslengine="off" /> 

压测结果:

webbench -c 4000 -t 30 http://10.103.10.140/workbench/index.jsp webbench - simple web benchmark 1.5 凯发天生赢家一触即发官网 copyright (c) radim kolar 1997-2004, gpl open source software.  benchmarking: get http://10.103.10.140/workbench/index.jsp 4000 clients, running 30 sec.  speed=484340 pages/min, 2441573 bytes/sec. requests: 242170 susceed, 0 failed. 

参考:

一、概述：

      在redis中，我们可以将set类型看作为没有排序的字符集合，和list类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为o(1)，即常量时间内完成次操作。set可包含的最大元素数量是4294967295。
      和list类型不同的是，set集合中不允许出现重复的元素，这一点和c 标准库中的set容器是完全相同的。换句话说，如果多次添加相同元素，set中将仅保留该元素的一份拷贝。和list类型相比，set类型在功能上还存在着一个非常重要的特性，即在服务器端完成多个sets之间的聚合计算操作，如unions、intersections和differences。由于这些操作均在服务端完成，因此效率极高，而且也节省了大量的网络io开销。

二、相关命令列表：

三、命令示例：

   1. sadd/smembers/scard/sismember:
    #在shell命令行下启动redis的客户端程序。
    /> redis-cli
    #插入测试数据，由于该键myset之前并不存在，因此参数中的三个成员都被正常插入。
    redis 127.0.0.1:6379> sadd myset a b c
    (integer) 3
    #由于参数中的a在myset中已经存在，因此本次操作仅仅插入了d和e两个新成员。
    redis 127.0.0.1:6379> sadd myset a d e
    (integer) 2
    #判断a是否已经存在，返回值为1表示存在。
    redis 127.0.0.1:6379> sismember myset a
    (integer) 1
    #判断f是否已经存在，返回值为0表示不存在。
    redis 127.0.0.1:6379> sismember myset f
    (integer) 0
    #通过smembers命令查看插入的结果，从结果可以，输出的顺序和插入顺序无关。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    5) "e"
    #获取set集合中元素的数量。
    redis 127.0.0.1:6379> scard myset
    (integer) 5

    2. spop/srem/srandmember/smove:
    #删除该键，便于后面的测试。
    redis 127.0.0.1:6379> del myset
    (integer) 1
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    #查看set中成员的位置。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    4) "b"
    #从结果可以看出，该命令确实是随机的返回了某一成员。
    redis 127.0.0.1:6379> srandmember myset
    "c"
    #set中尾部的成员b被移出并返回，事实上b并不是之前插入的第一个或最后一个成员。
    redis 127.0.0.1:6379> spop myset
    "b"
    #查看移出后set的成员信息。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    2) "d"
    3) "a"
    #从set中移出a、d和f三个成员，其中f并不存在，因此只有a和d两个成员被移出，返回为2。
    redis 127.0.0.1:6379> srem myset a d f
    (integer) 2
    #查看移出后的输出结果。
    redis 127.0.0.1:6379> smembers myset
    1) "c"
    #为后面的smove命令准备数据。
    redis 127.0.0.1:6379> sadd myset a b
    (integer) 2
    redis 127.0.0.1:6379> sadd myset2 c d
    (integer) 2
    #将a从myset移到myset2，从结果可以看出移动成功。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 1
    #再次将a从myset移到myset2，由于此时a已经不是myset的成员了，因此移动失败并返回0。
    redis 127.0.0.1:6379> smove myset myset2 a
    (integer) 0
    #分别查看myset和myset2的成员，确认移动是否真的成功。
    redis 127.0.0.1:6379> smembers myset
    1) "b"
    redis 127.0.0.1:6379> smembers myset2
    1) "c"
    2) "d"
    3) "a"

   3. sdiff/sdiffstore/sinter/sinterstore:
    #为后面的命令准备测试数据。
    redis 127.0.0.1:6379> sadd myset a b c d
    (integer) 4
    redis 127.0.0.1:6379> sadd myset2 c
    (integer) 1
    redis 127.0.0.1:6379> sadd myset3 a c e
    (integer) 3
    #myset和myset2相比，a、b和d三个成员是两者之间的差异成员。再用这个结果继续和myset3进行差异比较，b和d是myset3不存在的成员。
    redis 127.0.0.1:6379> sdiff myset myset2 myset3
    1) "d"
    2) "b"
    #将3个集合的差异成员存在在diffkey关联的set中，并返回插入的成员数量。
    redis 127.0.0.1:6379> sdiffstore diffkey myset myset2 myset3
    (integer) 2
    #查看一下sdiffstore的操作结果。
    redis 127.0.0.1:6379> smembers diffkey
    1) "d"
    2) "b"
    #从之前准备的数据就可以看出，这三个set的成员交集只有c。
    redis 127.0.0.1:6379> sinter myset myset2 myset3
    1) "c"
    #将3个集合中的交集成员存储到与interkey关联的set中，并返回交集成员的数量。
    redis 127.0.0.1:6379> sinterstore interkey myset myset2 myset3
    (integer) 1
    #查看一下sinterstore的操作结果。
    redis 127.0.0.1:6379> smembers interkey
    1) "c"
    #获取3个集合中的成员的并集。    
    redis 127.0.0.1:6379> sunion myset myset2 myset3
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"
    #将3个集合中成员的并集存储到unionkey关联的set中，并返回并集成员的数量。
    redis 127.0.0.1:6379> sunionstore unionkey myset myset2 myset3
    (integer) 5
    #查看一下suiionstore的操作结果。
    redis 127.0.0.1:6379> smembers unionkey
    1) "b"
    2) "c"
    3) "d"
    4) "e"
    5) "a"

四、应用范围：

      1). 可以使用redis的set数据类型跟踪一些唯一性数据，比如访问某一博客的唯一ip地址信息。对于此场景，我们仅需在每次访问该博客时将访问者的ip存入redis中，set数据类型会自动保证ip地址的唯一性。
      2). 充分利用set类型的服务端聚合操作方便、高效的特性，可以用于维护数据对象之间的关联关系。比如所有购买某一电子设备的客户id被存储在一个指定的set中，而购买另外一种电子产品的客户id被存储在另外一个set中，如果此时我们想获取有哪些客户同时购买了这两种商品时，set的intersections命令就可以充分发挥它的方便和效率的优势了。

一、概述：

      我们可以将redis中的hashes类型看成具有string key和string value的map容器。所以该类型非常适合于存储值对象的信息。如username、password和age等。如果hash中包含很少的字段，那么该类型的数据也将仅占用很少的磁盘空间。每一个hash可以存储4294967295个键值对。

二、相关命令列表：

三、命令示例：

    1. hset/hget/hdel/hexists/hlen/hsetnx:
    #在shell命令行启动redis客户端程序
    /> redis-cli
    #给键值为myhash的键设置字段为field1，值为stephen。
    redis 127.0.0.1:6379> hset myhash field1 "stephen"
    (integer) 1
    #获取键值为myhash，字段为field1的值。
    redis 127.0.0.1:6379> hget myhash field1
    "stephen"
    #myhash键中不存在field2字段，因此返回nil。
    redis 127.0.0.1:6379> hget myhash field2
    (nil)
    #给myhash关联的hashes值添加一个新的字段field2，其值为liu。
    redis 127.0.0.1:6379> hset myhash field2 "liu"
    (integer) 1
    #获取myhash键的字段数量。
    redis 127.0.0.1:6379> hlen myhash
    (integer) 2
    #判断myhash键中是否存在字段名为field1的字段，由于存在，返回值为1。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 1
    #删除myhash键中字段名为field1的字段，删除成功返回1。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 1
    #再次删除myhash键中字段名为field1的字段，由于上一条命令已经将其删除，因为没有删除，返回0。
    redis 127.0.0.1:6379> hdel myhash field1
    (integer) 0
    #判断myhash键中是否存在field1字段，由于上一条命令已经将其删除，因为返回0。
    redis 127.0.0.1:6379> hexists myhash field1
    (integer) 0
    #通过hsetnx命令给myhash添加新字段field1，其值为stephen，因为该字段已经被删除，所以该命令添加成功并返回1。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 1
    #由于myhash的field1字段已经通过上一条命令添加成功，因为本条命令不做任何操作后返回0。
    redis 127.0.0.1:6379> hsetnx myhash field1 stephen
    (integer) 0

   2. hincrby：
    #删除该键，便于后面示例的测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #准备测试数据，该myhash的field字段设定值1。
    redis 127.0.0.1:6379> hset myhash field 5
    (integer) 1
    #给myhash的field字段的值加1，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field 1
    (integer) 6
    #给myhash的field字段的值加-1，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -1
    (integer) 5
    #给myhash的field字段的值加-10，返回加后的结果。
    redis 127.0.0.1:6379> hincrby myhash field -10
    (integer) -5   

    3. hgetall/hkeys/hvals/hmget/hmset:
    #删除该键，便于后面示例测试。
    redis 127.0.0.1:6379> del myhash
    (integer) 1
    #为该键myhash，一次性设置多个字段，分别是field1 = "hello", field2 = "world"。
    redis 127.0.0.1:6379> hmset myhash field1 "hello" field2 "world"
    ok
    #获取myhash键的多个字段，其中field3并不存在，因为在返回结果中与该字段对应的值为nil。
    redis 127.0.0.1:6379> hmget myhash field1 field2 field3
    1) "hello"
    2) "world"
    3) (nil)
    #返回myhash键的所有字段及其值，从结果中可以看出，他们是逐对列出的。
    redis 127.0.0.1:6379> hgetall myhash
    1) "field1"
    2) "hello"
    3) "field2"
    4) "world"
    #仅获取myhash键中所有字段的名字。
    redis 127.0.0.1:6379> hkeys myhash
    1) "field1"
    2) "field2"
    #仅获取myhash键中所有字段的值。
    redis 127.0.0.1:6379> hvals myhash
    1) "hello"
    2) "world" 

一、概述：

      在redis中，list类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。list中可以包含的最大元素数量是4294967295。
      从元素插入和删除的效率视角来看，如果我们是在链表的两头插入或删除元素，这将会是非常高效的操作，即使链表中已经存储了百万条记录，该操作也可以在常量时间内完成。然而需要说明的是，如果元素插入或删除操作是作用于链表中间，那将会是非常低效的。相信对于有良好数据结构基础的开发者而言，这一点并不难理解。

二、相关命令列表：

三、命令示例：

    1. lpush/lpushx/lrange:
    /> redis-cli    #在shell提示符下启动redis客户端工具。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #mykey键并不存在，该命令会创建该键及与其关联的list，之后在将参数中的values从左到右依次插入。
    redis 127.0.0.1:6379> lpush mykey a b c d
    (integer) 4
    #取从位置0开始到位置2结束的3个元素。
    redis 127.0.0.1:6379> lrange mykey 0 2
    1) "d"
    2) "c"
    3) "b"
    #取链表中的全部元素，其中0表示第一个元素，-1表示最后一个元素。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "d"
    2) "c"
    3) "b"
    4) "a"
    #mykey2键此时并不存在，因此该命令将不会进行任何操作，其返回值为0。
    redis 127.0.0.1:6379> lpushx mykey2 e
    (integer) 0
    #可以看到mykey2没有关联任何list value。
    redis 127.0.0.1:6379> lrange mykey2 0 -1
    (empty list or set)
    #mykey键此时已经存在，所以该命令插入成功，并返回链表中当前元素的数量。
    redis 127.0.0.1:6379> lpushx mykey e
    (integer) 5
    #获取该键的list value的头部元素。
    redis 127.0.0.1:6379> lrange mykey 0 0
    1) "e"

    2. lpop/llen:
    redis 127.0.0.1:6379> lpush mykey a b c d
    (integer) 4
    redis 127.0.0.1:6379> lpop mykey
    "d"
    redis 127.0.0.1:6379> lpop mykey
    "c"
    #在执行lpop命令两次后，链表头部的两个元素已经被弹出，此时链表中元素的数量是2
    redis 127.0.0.1:6379> llen mykey
    (integer) 2

   3. lrem/lset/lindex/ltrim:
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> lpush mykey a b c d a c
    (integer) 6
    #从头部(left)向尾部(right)变量链表，删除2个值等于a的元素，返回值为实际删除的数量。
    redis 127.0.0.1:6379> lrem mykey 2 a
    (integer) 2
    #看出删除后链表中的全部元素。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "c"
    2) "d"
    3) "c"
    4) "b"
    #获取索引值为1(头部的第二个元素)的元素值。
    redis 127.0.0.1:6379> lindex mykey 1
    "d"
    #将索引值为1(头部的第二个元素)的元素值设置为新值e。
    redis 127.0.0.1:6379> lset mykey 1 e
    ok
    #查看是否设置成功。
    redis 127.0.0.1:6379> lindex mykey 1
    "e"
    #索引值6超过了链表中元素的数量，该命令返回nil。
    redis 127.0.0.1:6379> lindex mykey 6
    (nil)
    #设置的索引值6超过了链表中元素的数量，设置失败，该命令返回错误信息。
    redis 127.0.0.1:6379> lset mykey 6 hh
    (error) err index out of range
    #仅保留索引值0到2之间的3个元素，注意第0个和第2个元素均被保留。
    redis 127.0.0.1:6379> ltrim mykey 0 2
    ok
    #查看trim后的结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "c"
    2) "e"
    3) "c"

    4. linsert:
    #删除该键便于后面的测试。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #为后面的示例准备测试数据。
    redis 127.0.0.1:6379> lpush mykey a b c d e
    (integer) 5
    #在a的前面插入新元素a1。
    redis 127.0.0.1:6379> linsert mykey before a a1
    (integer) 6
    #查看是否插入成功，从结果看已经插入。注意lindex的index值是0-based。
    redis 127.0.0.1:6379> lindex mykey 0
    "e"
    #在e的后面插入新元素e2，从返回结果看已经插入成功。
    redis 127.0.0.1:6379> linsert mykey after e e2
    (integer) 7
    #再次查看是否插入成功。
    redis 127.0.0.1:6379> lindex mykey 1
    "e2"
    #在不存在的元素之前或之后插入新元素，该命令操作失败，并返回-1。
    redis 127.0.0.1:6379> linsert mykey after k a
    (integer) -1
    #为不存在的key插入新元素，该命令操作失败，返回0。
    redis 127.0.0.1:6379> linsert mykey1 after a a2
    (integer) 0

    5. rpush/rpushx/rpop/rpoplpush:
    #删除该键，以便于后面的测试。
    redis 127.0.0.1:6379> del mykey
    (integer) 1
    #从链表的尾部插入参数中给出的values，插入顺序是从左到右依次插入。
    redis 127.0.0.1:6379> rpush mykey a b c d
    (integer) 4
    #通过lrange的可以获悉rpush在插入多值时的插入顺序。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    #该键已经存在并且包含4个元素，rpushx命令将执行成功，并将元素e插入到链表的尾部。
    redis 127.0.0.1:6379> rpushx mykey e
    (integer) 5
    #通过lindex命令可以看出之前的rpushx命令确实执行成功，因为索引值为4的元素已经是新元素了。
    redis 127.0.0.1:6379> lindex mykey 4
    "e"
    #由于mykey2键并不存在，因此该命令不会插入数据，其返回值为0。
    redis 127.0.0.1:6379> rpushx mykey2 e
    (integer) 0
    #在执行rpoplpush命令前，先看一下mykey中链表的元素有哪些，注意他们的位置关系。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    5) "e"
    #将mykey的尾部元素e弹出，同时再插入到mykey2的头部(原子性的完成这两步操作)。
    redis 127.0.0.1:6379> rpoplpush mykey mykey2
    "e"
    #通过lrange命令查看mykey在弹出尾部元素后的结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "a"
    2) "b"
    3) "c"
    4) "d"
    #通过lrange命令查看mykey2在插入元素后的结果。
    redis 127.0.0.1:6379> lrange mykey2 0 -1
    1) "e"
    #将source和destination设为同一键，将mykey中的尾部元素移到其头部。
    redis 127.0.0.1:6379> rpoplpush mykey mykey
    "d"
    #查看移动结果。
    redis 127.0.0.1:6379> lrange mykey 0 -1
    1) "d"
    2) "a"
    3) "b"
    4) "c"

四、链表结构的小技巧：

      针对链表结构的value，redis在其官方文档中给出了一些实用技巧，如rpoplpush命令，下面给出具体的解释。
      redis链表经常会被用于消息队列的服务，以完成多程序之间的消息交换。假设一个应用程序正在执行lpush操作向链表中添加新的元素，我们通常将这样的程序称之为"生产者(producer)"，而另外一个应用程序正在执行rpop操作从链表中取出元素，我们称这样的程序为"消费者(consumer)"。如果此时，消费者程序在取出消息元素后立刻崩溃，由于该消息已经被取出且没有被正常处理，那么我们就可以认为该消息已经丢失，由此可能会导致业务数据丢失，或业务状态的不一致等现象的发生。然而通过使用rpoplpush命令，消费者程序在从主消息队列中取出消息之后再将其插入到备份队列中，直到消费者程序完成正常的处理逻辑后再将该消息从备份队列中删除。同时我们还可以提供一个守护进程，当发现备份队列中的消息过期时，可以重新将其再放回到主消息队列中，以便其它的消费者程序继续处理。

1.使用key值前缀来作命名空间

虽然说redis支持多个数据库（默认32个，可以配置更多），但是除了默认的0号库以外，其它的都需要通过一个额外请求才能使用。所以用前缀作为命名空间可能会更明智一点。

另外，在使用前缀作为命名空间区隔不同key的时候，最好在程序中使用全局配置来实现，直接在代码里写前缀的做法要严格避免，这样可维护性实在太差了。

2.创建一个类似 ”registry” 的key用于标记key使用情况

为了更好的管理你的key值的使用，比如哪一类key值是属于哪个业务的，你通常会在内部wiki或者什么地方创建一个文档，通过查询这个文档，我们能够知道redis中的key都是什么作用。

与之结合，一个推荐的做法是，在redis里面保存一个registry值，这个值的名字可以类似于 __key_registry__ 这样的，这个key对应的value就是你文档的位置，这样我们在使用redis的时候，就能通过直接查询这个值获取到当前redis的使用情况了。

3.注意垃圾回收

redis是一个提供持久化功能的内存数据库，如果你不指定上面值的过期时间，并且也不进行定期的清理工作，那么你的redis内存占用会越来越大，当有一天它超过了系统可用内存，那么swap上场，离性能陡降的时间就不远了。所以在redis中保存数据时，一定要预先考虑好数据的生命周期，这有很多方法可以实现。

比如你可以采用redis自带的过期时间为你的数据设定过期时间。但是自动过期有一个问题，很有可能导致你还有大量内存可用时，就让key过期去释放内存，或者是内存已经不足了key还没有过期。

如果你想更精准的控制你的数据过期，你可以用一个zset来维护你的数据更新程度，你可以用时间戳作为score值，每次更新操作时更新一下score，这样你就得到了一个按更新时间排序序列串，你可以轻松地找到最老的数据，并且从最老的数据开始进行删除，一直删除到你的空间足够为止。

4.设计好你的sharding机制

redis目前并不支持sharding，但是当你的数据量超过单机内存时，你不得不考虑sharding的事（注意：slave不是用来做sharding操作的，只是数据的一个备份和读写分离而已）。

所以你可能需要考虑好数据量大了后的分片问题，比如你可以在只有一台机器的时候就在程序上设定一致性hash机制，虽然刚开始所有数据都hash到一台机器，但是当你机器越加越多的时候，你就只需要迁移少量的数据就能完成了。

5.不要有个锤子看哪都是钉子

当你使用redis构建你的服务的时候，一定要记住，你只是找了一个合适的工具来实现你需要的功能。而不是说你在用redis构建一个服务，这是很不同的，你把redis当作你很多工具中的一个，只在合适使用的时候再使用它，在不合适的时候选择其它的方法。

来源：

redis最为常用的数据类型主要有以下五种：

• string
• hash
• list
• set
• sorted set

在具体描述这几种数据类型之前，我们先通过一张图了解下redis内部内存管理中是如何描述这些不同数据类型的：

首先redis内部使用一个redisobject对象来表示所有的key和value,redisobject最主要的信息如上图所示：type代表一个value对象具体是何种数据类型，encoding是不同数据类型在redis内部的存储方式，比如：type=string代表value存储的是一个普通字符串，那么对应的encoding可以是raw或者是int,如果是int则代表实际redis内部是按数值型类存储和表示这个字符串的，当然前提是这个字符串本身可以用数值表示，比如:"123" "456"这样的字符串。

这里需要特殊说明一下vm字段，只有打开了redis的虚拟内存功能，此字段才会真正的分配内存，该功能默认是关闭状态的，该功能会在后面具体描述。通过上图我们可以发现redis使用redisobject来表示所有的key/value数据是比较浪费内存的，当然这些内存管理成本的付出主要也是为了给redis不同数据类型提供一个统一的管理接口，实际作者也提供了多种方法帮助我们尽量节省内存使用，我们随后会具体讨论。

下面我们先来逐一的分析下这五种数据类型的使用和内部实现方式：

• string

  常用命令：

  set,get,decr,incr,mget 等。

  应用场景：

  string是最常用的一种数据类型，普通的key/value存储都可以归为此类，这里就不所做解释了。

  实现方式：

  string在redis内部存储默认就是一个字符串，被redisobject所引用，当遇到incr,decr等操作时会转成数值型进行计算，此时redisobject的encoding字段为int。

• hash

  常用命令：

  hget,hset,hgetall 等。

  应用场景：

  我们简单举个实例来描述下hash的应用场景，比如我们要存储一个用户信息对象数据，包含以下信息：

  用户id为查找的key，存储的value用户对象包含姓名，年龄，生日等信息，如果用普通的key/value结构来存储，主要有以下2种存储方式：

  第一种方式将用户id作为查找key,把其他信息封装成一个对象以序列化的方式存储，这种方式的缺点是，增加了序列化/反序列化的开销，并且在需要修改其中一项信息时，需要把整个对象取回，并且修改操作需要对并发进行保护，引入cas等复杂问题。

  第二种方法是这个用户信息对象有多少成员就存成多少个key-value对儿，用用户id 对应属性的名称作为唯一标识来取得对应属性的值，虽然省去了序列化开销和并发问题，但是用户id为重复存储，如果存在大量这样的数据，内存浪费还是非常可观的。

  那么redis提供的hash很好的解决了这个问题，redis的hash实际是内部存储的value为一个hashmap，并提供了直接存取这个map成员的接口，如下图：

  也就是说，key仍然是用户id, value是一个map，这个map的key是成员的属性名，value是属性值，这样对数据的修改和存取都可以直接通过其内部map的key(redis里称内部map的key为field), 也就是通过 key(用户id) field(属性标签) 就可以操作对应属性数据了，既不需要重复存储数据，也不会带来序列化和并发修改控制的问题。很好的解决了问题。

  这里同时需要注意，redis提供了接口(hgetall)可以直接取到全部的属性数据,但是如果内部map的成员很多，那么涉及到遍历整个内部map的操作，由于redis单线程模型的缘故，这个遍历操作可能会比较耗时，而另其它客户端的请求完全不响应，这点需要格外注意。

  实现方式：

  上面已经说到redis hash对应value内部实际就是一个hashmap，实际这里会有2种不同实现，这个hash的成员比较少时redis为了节省内存会采用类似一维数组的方式来紧凑存储，而不会采用真正的hashmap结构，对应的value redisobject的encoding为zipmap,当成员数量增大时会自动转成真正的hashmap,此时encoding为ht。

• list

  常用命令：

  lpush,rpush,lpop,rpop,lrange等。

  应用场景：

  redis list的应用场景非常多，也是redis最重要的数据结构之一，比如twitter的关注列表，粉丝列表等都可以用redis的list结构来实现，比较好理解，这里不再重复。

  实现方式：

  redis list的实现为一个双向链表，即可以支持反向查找和遍历，更方便操作，不过带来了部分额外的内存开销，redis内部的很多实现，包括发送缓冲队列等也都是用的这个数据结构。

• set

  常用命令：

  sadd,spop,smembers,sunion 等。

  应用场景：

  redis set对外提供的功能与list类似是一个列表的功能，特殊之处在于set是可以自动排重的，当你需要存储一个列表数据，又不希望出现重复数据时，set是一个很好的选择，并且set提供了判断某个成员是否在一个set集合内的重要接口，这个也是list所不能提供的。

  实现方式：

  set 的内部实现是一个 value永远为null的hashmap，实际就是通过计算hash的方式来快速排重的，这也是set能提供判断一个成员是否在集合内的原因。

• sorted set

  常用命令：

  zadd,zrange,zrem,zcard等

  使用场景：

  redis sorted set的使用场景与set类似，区别是set不是自动有序的，而sorted set可以通过用户额外提供一个优先级(score)的参数来为成员排序，并且是插入有序的，即自动排序。当你需要一个有序的并且不重复的集合列表，那么可以选择sorted set数据结构，比如twitter 的public timeline可以以发表时间作为score来存储，这样获取时就是自动按时间排好序的。

  实现方式：

  redis sorted set的内部使用hashmap和跳跃表(skiplist)来保证数据的存储和有序，hashmap里放的是成员到score的映射，而跳跃表里存放的是所有的成员，排序依据是hashmap里存的score,使用跳跃表的结构可以获得比较高的查找效率，并且在实现上比较简单。

常用内存优化手段与参数

通过我们上面的一些实现上的分析可以看出redis实际上的内存管理成本非常高，即占用了过多的内存，作者对这点也非常清楚，所以提供了一系列的参数和手段来控制和节省内存，我们分别来讨论下。

首先最重要的一点是不要开启redis的vm选项，即虚拟内存功能，这个本来是作为redis存储超出物理内存数据的一种数据在内存与磁盘换入换出的一个持久化策略，但是其内存管理成本也非常的高，并且我们后续会分析此种持久化策略并不成熟，所以要关闭vm功能，请检查你的redis.conf文件中 vm-enabled 为 no。

其次最好设置下redis.conf中的maxmemory选项，该选项是告诉redis当使用了多少物理内存后就开始拒绝后续的写入请求，该参数能很好的保护好你的redis不会因为使用了过多的物理内存而导致swap,最终严重影响性能甚至崩溃。

另外redis为不同数据类型分别提供了一组参数来控制内存使用，我们在前面详细分析过redis hash是value内部为一个hashmap，如果该map的成员数比较少，则会采用类似一维线性的紧凑格式来存储该map, 即省去了大量指针的内存开销，这个参数控制对应在redis.conf配置文件中下面2项：

hash-max-zipmap-entries 64  hash-max-zipmap-value 512  hash-max-zipmap-entries 

含义是当value这个map内部不超过多少个成员时会采用线性紧凑格式存储，默认是64,即value内部有64个以下的成员就是使用线性紧凑存储，超过该值自动转成真正的hashmap。

hash-max-zipmap-value 含义是当 value这个map内部的每个成员值长度不超过多少字节就会采用线性紧凑存储来节省空间。

以上2个条件任意一个条件超过设置值都会转换成真正的hashmap，也就不会再节省内存了，那么这个值是不是设置的越大越好呢，答案当然是否定的，hashmap的优势就是查找和操作的时间复杂度都是o(1)的，而放弃hash采用一维存储则是o(n)的时间复杂度，如果

成员数量很少，则影响不大，否则会严重影响性能，所以要权衡好这个值的设置，总体上还是最根本的时间成本和空间成本上的权衡。

同样类似的参数还有：

list-max-ziplist-entries 512

说明：list数据类型多少节点以下会采用去指针的紧凑存储格式。

list-max-ziplist-value 64 

说明：list数据类型节点值大小小于多少字节会采用紧凑存储格式。

set-max-intset-entries 512 

说明：set数据类型内部数据如果全部是数值型，且包含多少节点以下会采用紧凑格式存储。

最后想说的是redis内部实现没有对内存分配方面做过多的优化，在一定程度上会存在内存碎片，不过大多数情况下这个不会成为redis的性能瓶颈，不过如果在redis内部存储的大部分数据是数值型的话，redis内部采用了一个shared integer的方式来省去分配内存的开销，即在系统启动时先分配一个从1~n 那么多个数值对象放在一个池子中，如果存储的数据恰好是这个数值范围内的数据，则直接从池子里取出该对象，并且通过引用计数的方式来共享，这样在系统存储了大量数值下，也能一定程度上节省内存并且提高性能，这个参数值n的设置需要修改源代码中的一行宏定义redis_shared_integers，该值默认是10000，可以根据自己的需要进行修改，修改后重新编译就可以了。

redis的持久化机制

redis由于支持非常丰富的内存数据结构类型，如何把这些复杂的内存组织方式持久化到磁盘上是一个难题，所以redis的持久化方式与传统数据库的方式有比较多的差别，redis一共支持四种持久化方式，分别是：

• 定时快照方式(snapshot)
• 基于语句追加文件的方式(aof)
• 虚拟内存(vm)
• diskstore方式

在设计思路上，前两种是基于全部数据都在内存中，即小数据量下提供磁盘落地功能，而后两种方式则是作者在尝试存储数据超过物理内存时，即大数据量的数据存储，截止到本文，后两种持久化方式仍然是在实验阶段，并且vm方式基本已经被作者放弃，所以实际能在生产环境用的只有前两种，换句话说redis目前还只能作为小数据量存储（全部数据能够加载在内存中），海量数据存储方面并不是redis所擅长的领域。下面分别介绍下这几种持久化方式：

定时快照方式(snapshot)：

该持久化方式实际是在redis内部一个定时器事件，每隔固定时间去检查当前数据发生的改变次数与时间是否满足配置的持久化触发的条件，如果满足则通过操作系统fork调用来创建出一个子进程，这个子进程默认会与父进程共享相同的地址空间，这时就可以通过子进程来遍历整个内存来进行存储操作，而主进程则仍然可以提供服务，当有写入时由操作系统按照内存页(page)为单位来进行copy-on-write保证父子进程之间不会互相影响。

该持久化的主要缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。

基于语句追加方式(aof)：

aof方式实际类似mysql的基于语句的binlog方式，即每条会使redis内存数据发生改变的命令都会追加到一个log文件中，也就是说这个log文件就是redis的持久化数据。

aof的方式的主要缺点是追加log文件可能导致体积过大，当系统重启恢复数据时如果是aof的方式则加载数据会非常慢，几十g的数据可能需要几小时才能加载完，当然这个耗时并不是因为磁盘文件读取速度慢，而是由于读取的所有命令都要在内存中执行一遍。另外由于每条命令都要写log,所以使用aof的方式，redis的读写性能也会有所下降。

虚拟内存方式：

虚拟内存方式是redis来进行用户空间的数据换入换出的一个策略，此种方式在实现的效果上比较差，主要问题是代码复杂，重启慢，复制慢等等，目前已经被作者放弃。

diskstore方式：

diskstore方式是作者放弃了虚拟内存方式后选择的一种新的实现方式，也就是传统的b-tree的方式，目前仍在实验阶段，后续是否可用我们可以拭目以待。

redis持久化磁盘io方式及其带来的问题

有redis线上运维经验的人会发现redis在物理内存使用比较多，但还没有超过实际物理内存总容量时就会发生不稳定甚至崩溃的问题，有人认为是基于快照方式持久化的fork系统调用造成内存占用加倍而导致的，这种观点是不准确的，因为fork 调用的copy-on-write机制是基于操作系统页这个单位的，也就是只有有写入的脏页会被复制，但是一般你的系统不会在短时间内所有的页都发生了写入而导致复制，那么是什么原因导致redis崩溃的呢？

答案是redis的持久化使用了buffer io造成的，所谓buffer io是指redis对持久化文件的写入和读取操作都会使用物理内存的page cache,而大多数数据库系统会使用direct io来绕过这层page cache并自行维护一个数据的cache，而当redis的持久化文件过大(尤其是快照文件)，并对其进行读写时，磁盘文件中的数据都会被加载到物理内存中作为操作系统对该文件的一层cache,而这层cache的数据与redis内存中管理的数据实际是重复存储的，虽然内核在物理内存紧张时会做page cache的剔除工作，但内核很可能认为某块page cache更重要，而让你的进程开始swap ,这时你的系统就会开始出现不稳定或者崩溃了。我们的经验是当你的redis物理内存使用超过内存总容量的3/5时就会开始比较危险了。

下图是redis在读取或者写入快照文件dump.rdb后的内存数据图：

总结：

1. 根据业务需要选择合适的数据类型，并为不同的应用场景设置相应的紧凑存储参数。
2. 当业务场景不需要数据持久化时，关闭所有的持久化方式可以获得最佳的性能以及最大的内存使用量。
3. 如果需要使用持久化，根据是否可以容忍重启丢失部分数据在快照方式与语句追加方式之间选择其一，不要使用虚拟内存以及diskstore方式。
4. 不要让你的redis所在机器物理内存使用超过实际内存总量的3/5。

转载自：

内容不断更新，目前包括协议中握手和数据帧的分析

1.1 背景

1.2 协议概览

协议包含两部分：握手，数据传输。

客户端的握手如下：
get /chat http/1.1
host: server.example.com
upgrade: websocket
connection: upgrade
sec-websocket-key: dghlihnhbxbszsbub25jzq==
origin: http://example.com
sec-websocket-protocol: chat, superchat
sec-websocket-version: 13

服务端的握手如下：
        http/1.1 101 switching protocols         upgrade: websocket         connection: upgrade         sec-websocket-accept: s3pplmbitxaq9kygzzhzrbk xoo=         sec-websocket-protocol: chat

客户端和服务端都发送了握手，并且成功，数据传输即可开始。

1.3 发起握手

发起握手是为了兼容基于http的服务端程序，这样一个端口可以同时处理http客户端和websocket客户端

因此websocket客户端握手是一个http upgrade请求：
        get /chat http/1.1         host: server.example.com         upgrade: websocket         connection: upgrade         sec-websocket-key: dghlihnhbxbszsbub25jzq==         origin: http://example.com         sec-websocket-protocol: chat, superchat         sec-websocket-version: 13

握手中的域的顺序是任意的。

5 数据帧

5.1 概述

webscoket协议中，数据以帧序列的形式传输。

考虑到数据安全性，客户端向服务器传输的数据帧必须进行掩码处理。服务器若接收到未经过掩码处理的数据帧，则必须主动关闭连接。

服务器向客户端传输的数据帧一定不能进行掩码处理。客户端若接收到经过掩码处理的数据帧，则必须主动关闭连接。

针对上情况，发现错误的一方可向对方发送close帧（状态码是1002，表示协议错误），以关闭连接。

5.2 帧协议

websocket数据帧结构如下图所示：

      0                   1                   2                   3       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1       - - - - ------- - ------------- -------------------------------       |f|r|r|r| opcode|m| payload len |    extended payload length    |      |i|s|s|s|  (4)  |a|     (7)     |             (16/64)           |      |n|v|v|v|       |s|             |   (if payload len==126/127)   |      | |1|2|3|       |k|             |                               |       - - - - ------- - -------------  - - - - - - - - - - - - - - -        |     extended payload length continued, if payload len == 127  |        - - - - - - - - - - - - - - -  -------------------------------       |                               |masking-key, if mask set to 1  |       ------------------------------- -------------------------------       | masking-key (continued)       |          payload data         |       -------------------------------- - - - - - - - - - - - - - - -        :                     payload data continued ...                :        - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -        |                     payload data continued ...                |       --------------------------------------------------------------- 

fin：1位
表示这是消息的最后一帧（结束帧），一个消息由一个或多个数据帧构成。若消息由一帧构成，起始帧即结束帧。

rsv1，rsv2，rsv3：各1位
must be 0 unless an extension is negotiated that defines meanings for non-zero values. if a nonzero value is received and none of the negotiated extensions defines the meaning of such a nonzero value, the receiving endpoint must _fail the websocket connection_.
这里我翻译不好，大致意思是如果未定义扩展，各位是0；如果定义了扩展，即为非0值。如果接收的帧此处非0，扩展中却没有该值的定义，那么关闭连接。

opcode：4位
解释payloaddata，如果接收到未知的opcode，接收端必须关闭连接。
0x0表示附加数据帧
0x1表示文本数据帧
0x2表示二进制数据帧
0x3-7暂时无定义，为以后的非控制帧保留
0x8表示连接关闭
0x9表示ping
0xa表示pong
0xb-f暂时无定义，为以后的控制帧保留

mask：1位
用于标识payloaddata是否经过掩码处理。如果是1，masking-key域的数据即是掩码密钥，用于解码payloaddata。客户端发出的数据帧需要进行掩码处理，所以此位是1。

payload length：7位，7 16位，7 64位
payloaddata的长度（以字节为单位）。
如果其值在0-125，则是payload的真实长度。
如果值是126，则后面2个字节形成的16位无符号整型数的值是payload的真实长度。注意，网络字节序，需要转换。
如果值是127，则后面8个字节形成的64位无符号整型数的值是payload的真实长度。注意，网络字节序，需要转换。
长度表示遵循一个原则，用最少的字节表示长度（我理解是尽量减少不必要的传输）。举例说，payload真实长度是124，在0-125之间，必须用前7位表示；不允许长度1是126或127，然后长度2是124，这样违反原则。
payload长度是extensiondata长度与applicationdata长度之和。extensiondata长度可能是0，这种情况下，payload长度即是applicationdata长度。

websocket协议规定数据通过帧序列传输。

客户端必须对其发送到服务器的所有帧进行掩码处理。

服务器一旦收到无掩码帧，将关闭连接。服务器可能发送一个状态码是1002（表示协议错误）的close帧。

而服务器发送客户端的数据帧不做掩码处理，一旦客户端发现经过掩码处理的帧，将关闭连接。客户端可能使用状态码1002。

消息分片

分片目的是发送长度未知的消息。如果不分片发送，即一帧，就需要缓存整个消息，计算其长度，构建frame并发送；使用分片的话，可使用一个大小合适的buffer，用消息内容填充buffer，填满即发送出去。

分片规则：

1.一个未分片的消息只有一帧（fin为1，opcode非0）

2.一个分片的消息由起始帧（fin为0，opcode非0），若干（0个或多个）帧（fin为0，opcode为0），结束帧（fin为1，opcode为0）。

3.控制帧可以出现在分片消息中间，但控制帧本身不允许分片。

4.分片消息必须按次序逐帧发送。

5.如果未协商扩展的情况下，两个分片消息的帧之间不允许交错。

6.能够处理存在于分片消息帧之间的控制帧

7.发送端为非控制消息构建长度任意的分片

8.client和server兼容接收分片消息与非分片消息

9.控制帧不允许分片，中间媒介不允许改变分片结构（即为控制帧分片）

10.如果使用保留位，中间媒介不知道其值表示的含义，那么中间媒介不允许改变消息的分片结构

11.如果协商扩展，中间媒介不知道，那么中间媒介不允许改变消息的分片结构，同样地，如果中间媒介不了解一个连接的握手信息，也不允许改变该连接的消息的分片结构

12.由于上述规则，一个消息的所有分片是同一数据类型（由第一个分片的opcode定义）的数据。因为控制帧不允许分片，所以一个消息的所有分片的数据类型是文本、二进制、opcode保留类型中的一种。

需要注意的是，如果控制帧不允许夹杂在一个消息的分片之间，延迟会较大，比如说当前正在传输一个较大的消息，此时的ping必须等待消息传输完成，才能发送出去，会导致较大的延迟。为了避免类似问题，需要允许控制帧夹杂在消息分片之间。

控制帧

根据官方文档整理，官方文档参考