专门做商标的网站有哪些wordpress用户无法登录

Redis

基于内存进⾏存储，⽀持 key-value 的存储形式，底层是⽤ C 语⾔编写的。
基于 key-value 形式的数据字典，结构⾮常简单，没有数据表的概念，直接⽤键值对的形式完成数据的管理，Redis ⽀持 5 种数据类型：

字符串
列表
集合
有序集合
哈希

安装 Redis
1、下载 Redis
https://redis.io/download

2、解压，并在本地硬盘任意位置创建⽂件夹，在其中创建 3 个⼦⽂件夹

bin：放置启动 Redis 的可执⾏⽂件
db：放置数据⽂件
etc：放置配置⽂件，设置 Redis 服务的端⼝、⽇志⽂件位置、数据⽂件位置…

启动 Redis 服务
1、进⼊ redis ⽬录，启动 redis-server。

sudo ./bin/redis-server ./etc/redis.conf

2、进⼊ redis ⽬录，启动 redis-cli，启动 Redis 的客户端管理窗⼝，在此窗⼝中即可操作 Redis 数据库。

./bin/redis-cli

3、对数据进⾏操作。

set key value
get key

4、关闭 Redis 服务。

shutdown

5、退出客户端，control+c。

基本知识
Redis是一个字典结构的存储服务器，一个Redis实例提供了多个用来存储数据的字典，客户端可以指定 将数据存储在哪个字典中。 这与在一个关系数据库实例中可以创建多个数据库类似（如下图所示），所以可以将其中的每个字典都 理解成一个独立的数据库。

Redis默认支持16个数据库，可以通过调整Redis的配置文件redis/redis.conf中的databases来修改这一 个值，设置完毕后重启Redis便完成配置。

Redis 使用的到底是多线程还是单线程？
因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就顺理成章地采用单线程的方案了。

Redis 概述
在我们日常的Java Web开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。

NoSQL 技术
为了克服上述的问题，Java Web项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。

Redis和MongoDB是当前使用最广泛的NoSQL，而就Redis技术而言，它的性能十分优越，可以支持每秒十几万此的读/写操作，其性能远超数据库，并且还支持集群、分布式、主从同步等配置，原则上可以无限扩展，让更多的数据存储在内存中，更让人欣慰的是它还支持一定的事务能力，这保证了高并发的场景下数据的安全和一致性。

Redis 在 Java Web 中的应用
Redis 在 Java Web 主要有两个应用场景：

存储 缓存 用的数据；
需要高速读/写的场合使用它快速读/写；

缓存
在日常对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用SQL语句去数据库进行读写操作时，数据库就会去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。

如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，那么这样速度明显就会快上不少，并且会极大减小数据库的压力，但是使用内存进行数据存储开销也是比较大的，限于成本的原因，一般我们只是使用 Redis 存储一些常用和主要的数据，比如用户登录的信息等。

一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：

**业务数据常用吗？命中率如何？**如果命中率很低，就没有必要写入缓存；
**该业务数据是读操作多，还是写操作多？**如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
**业务数据大小如何？**如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要；

高速读/写的场合
在如今的互联网中，越来越多的存在高并发的情况，比如天猫双11、抢红包、抢演唱会门票等，这些场合都是在某一个瞬间或者是某一个短暂的时刻有成千上万的请求到达服务器，如果单纯的使用数据库来进行处理，就算不崩，也会很慢的，轻则造成用户体验极差用户量流失，重则数据库瘫痪，服务宕机，而这样的场合都是不允许的！