在进行参数验证的时候，往往存在现有的约束注解不能满足的情况，此时就需要我们自己定义validation注解了，下面来介绍一下如何自己定义一个验证注解。

有关参数校验的使用可详见《springboot中参数校验（validation）使用》

在开发中，会经常需要进行参数的校验，比如接口层、业务层、持久层等，其中接口的参数校验就是最为常见的。这里就来看一下springboot中参数校验（validation）的使用。

关于如何自定义validation注解详见《springboot中参数校验（validation）注解自定义》

前言

以前做过一个有关redis的技术分享，这里将之前分享的内容做了抽减，来大概的介绍一下redis，以帮助快速入门，对redis有个概要性的了解，不会做深入的介绍。本文中代码由于是直接用以前PPT上的截图，所以没有贴源码，请谅解。

本文内容如有错误的地方，欢迎指正。

Redis是什么？

Redis是完全开源免费、遵守BSD协议的一个高性能的key-value数据库。据官方统计数据：redis读 110000次/秒，写 81000次/秒。目前已经有很多公司都在用redis，下面举几个例子：

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

服务器结构

在redis的头文件server.h中定义了服务器的数据结构，略见如下：（详细的可在文末的源码部分见得）

1
2
3
4
5
6
7

struct redisServer {

    //服务器的一些信息
    ·
    ·
    ·
}

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

Redis命令执行

Redis执行命令时都会先建立一个客户端，然后由客户端去和服务器连接，在执行命令（使用lua脚本执行亦如此，只不过lua的客户端是个伪客户端而已）。redis的命令执行中有一个核心部分，就是call()方法，call函数声明如下：

1

void call(client *c, int flags)

可见有两个参数，client是代表客户端（redis的命令执行都是以客户端向服务端发送的方式，请求执行的一方即为客户端）；flags是一个特殊标识。

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

Redis服务器初始化数据库的个数为16个，由server.h头文件中的宏定义而来，如下所示：

1

#define CONFIG_DEFAULT_DBNUM     16

并且每个数据库的结构都有一个redisDb构成，如下是redisDb的数据结构定义（server.h头文件中），各字段的含义可见上面的源码注释：

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

redis命令

在redis服务器中，对命令进行了结构封装，如下所示（server.h头文件中）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14

struct redisCommand {
    char *name;             //命令名称
    redisCommandProc *proc; //指向命令函数实现的指针
    int arity;              //参数的数量        
    char *sflags; /* Flags as string representation, one char per flag. */
    int flags;    /* The actual flags, obtained from the 'sflags' field. */
    /* Use a function to determine keys arguments in a command line.
     * Used for Redis Cluster redirect. */
    redisGetKeysProc *getkeys_proc;
    int firstkey; /* The first argument that's a key (0 = no keys) */
    int lastkey;  /* The last argument that's a key */
    int keystep;  /* The step between first and last key */
    long long microseconds, calls;//microseconds：命令执行时间；calls：命令调用的总次数
};

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

redis对象

在redis中，定义了5中基本对象，分别为string、list、set、zset、hash。而为了方便管理与操作，redis又对这5种对象进行了一次外围封装，如下所示（server.h头文件）：

1
2
3
4
5
6
7
8
9

typedef struct redisObject {
    unsigned type:4;       /* 对象类型 */
    unsigned encoding:4;   /* 编码类型 */
    unsigned lru:LRU_BITS; /* LRU time (relative to global lru_clock) or
                            * LFU data (least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount; /* 引用计数 */
    void *ptr;    /* 指向对象的指针 */
} robj;

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

zipmap

1. zipmap是为优化string映射到其他string这种结构而生的，故名思意其能节约内存。
2. zipmap是redis中hash结构的底层涉及之一。当hash存储的元素数量少的情况下，底层使用zipmap结构，一旦元素数量达到一个限定值的时候就会自动切换成哈希表。
3. 由于zipmap的特性，hash结构在存储的数据少的情况下，在内存使用方面又相当大的优势。

以下涉及到的源码均为redis5.0-rc3版本的代码【点击查看官方源码】

压缩列表（ziplist）

1. 压缩列表是一个特殊编码的列表，为节约内存而开发。
2. 压缩列表可以保存字符串和整型值，其中整数存放时仍是整数，而不会变成字符。
3. 压缩列表允许push和pop操作在时间复杂度为O(1)的情况下完成。但是每个操作都可能需要重新分配ziplist使用的内存，所以实际的复杂性受ziplist使用内存量及其变动的影响。
4. 压缩列表在redis中是列表键和哈希键的底层实现之一。
5. 由于压缩列表本就为节约内存而开发，且其改动的操作都可能会重新分配entry的内存，导致操作的时间复杂度增加，所以为了性能上不受影响，其适用于存储小整数值和较短的字符串。