memcache和redis都属于缓存但是memcache的存储大小是收到 限制的memcache的 键值长度是250，内存的大小限制是1M并且memcache不支持数据的持久化缓存
redis支持五种数据类型，string list set（集合） hash 和Sorted Set(有序集合)，并且redi是支持数据的持久化缓存，redis的两种机制AOF和RDB
Redis的持久化
- RDB
a) 简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
b) 对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。
c) 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。
d) 如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。
- AOF
a) 将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。
b) 默认的AOF持久化策略是每秒钟fsync一次；
c) AOF在文件中采用追加方式来写入，因此不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，当AOF文件的大小超过所设定的值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。
- RDB和AOF的区别：
a) RDB方式存的是数据，AOF方式存的是指令；
b) RDB和AOF可以同时使用，在这种情况下，如果redis重启的话，会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
c) 同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。
- AOF重写原理：
a) 首先，当重写开始时，创建一个重写子进程；
b) 子进程读取现有AOF文件中的指令解析并压缩至一个临时文件中；
c) 同时主进程接收到新的写指令时，一边继续向AOF文件中写入，以保证原有AOF文件的可用性，避免重写过程中发生意外，一边向内存缓冲区中写入；
d) 当子进程完成重写任务后，想主进程发送信号，主进程接收到信号后将内存缓冲区中新的写指令追加到新的AOF文件中；
e) 追加结束后，会用新的AOF文件替换旧的AOF文件，至此，重写结束；
Redis的主从
- 主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。
- redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。
- 主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能
Memecached重点启动设置参数
- –m：默认分配内存大小为64M，32位操作系统下每个进程最大分配内存为2G，所以如果需要分配更多的内存需要使用64位操作系统，但是这个不会一启动就占用，是随着需要逐步分配给各slab的。；
–I：调整分配page页的大小，默认1M，最小1K，最大128K；
–f：memcached默认情况下下一个slab的最大值为前一个的1.25倍，可通过此参数来设定；
–P：TCP端口设置，默认为11211；
–l：监听的IP地址，如果为本机可不设置；
–d：以守护进程的方式运行；
–u：指定用户；
–M：禁止LRU策略，内存耗尽时返回错误，而不是删除项；
–c：最大同时连接数，默认为1024；
–t：线程数，默认为4；