Redis各位肯定都是知道的，目前最流程的No SQL之一，在众多应用场景中都有使用，具有高性能，抗并发的特性，在Azure中Redis也是个客户常用的服务，接下来准备写个短篇系列的博客专门来介绍Azure上redis的使用
首先来看下Redis的常用场景，通过这个介绍也可以看下什么样的情况适合用Redis服务
| 模式 | 说明 |
缓存端
| 由于数据库可能很大，因此不建议将整个数据库加载到缓存中。 通常使用缓存端模式，只在需要时才将数据项加载到缓存中。 系统在更改后端数据时，也会同时更新分布到其他客户端的缓存。 另外，系统还可以设置数据项的过期时间，或者通过逐出策略将数据更新重新加载到缓存中。 |
| 内容缓存 | 大多数通过模板生成的网页会带有页眉、页脚、工具栏、菜单，等等。这些网页实际上不经常变化，不应以动态方式生成。 与使用后端数据存储相比，使用内存中缓存（例如 Azure Redis 缓存）可以让 Web 服务器快速访问此类静态内容。 此模式可减少以动态方式生成内容所需的处理时间和服务器负荷。 这样可以提高 Web 服务器的响应能力，减少处理负荷所需的服务器数。 Azure Redis 缓存提供 Redis 输出缓存提供程序，支持对 ASP.NET 使用此模式。 |
用户会话缓存
| 此模式通常用于购物车和其他用户历史记录类型的信息。Web 应用程序可能需要将此类信息与用户 Cookie 相关联。 在 Cookie 中存储过多内容可能会对性能造成负面影响，因为 Cookie 会变大，并且每次请求都需要传递和验证 Cookie。 常用解决方案是使用 Cookie 作为键来查询后端数据库中的数据。 使用内存中缓存（例如 Azure Redis 缓存）将信息与用户关联在速度上要比与整个关系数据库交互快得多 |
| 作业和消息队列 | 当应用程序收到请求时，通常还需要额外的时间来执行与请求相关联的操作。 通常会将运行时间较长的操作添加到队列中，留待以后处理（可能由其他服务器处理）。 这种将工作推迟的方法称为任务队列。 多种软件组件专用于提供任务队列支持。 Azure Redis 缓存也以分布式队列的方式提供此支持。 |
| 分布式事务 | 通常会要求应用程序能够以单个操作（原子操作）的方式对后端数据存储执行一系列命令。 所有命令都必须成功，否则，所有命令都必须回退到初始状态。 Azure Redis 缓存支持通过单个操作以事务形式执行一批命令。 |
如果符合这些场景的话，那么就可以尝试使用Redis，Azure上的Redis和其他服务一样，也是分不同的级别的
| 层 | 说明 |
| 基本 | 单节点缓存。 此层支持多种内存大小 (250 MB - 53 GB)。 此层适用于开发/测试和非关键型工作负荷。 基本层没有服务级别协议 (SLA) |
| 标准 | 的双节点（主/辅）配置中提供复制的缓存，并提供高可用性 SLA (99.9%) |
| 高级 | 高级层是面向企业的层。 高级层缓存支持更多的功能，吞吐量更高，延迟更低。 高级层中的缓存部署在更强大的硬件上，其性能优于基本层或标准层。 这种优势意味着，在缓存大小相同的情况下，高级层的吞吐量大于标准层。 |
不同的层功能也会有很大区别，简单来说可以用一张图来直观的看到不同层支持的功能
总体来说，
基本缓存是单个缓存节点，适用于开发/测试和非关键型工作负荷。基本级别没有服务级别协议。缓存节点的更新升级阶段，服务不可用，数据可能会丢失。
标准缓存在双节点主要/辅助配置中提供一个复制的缓存。微软会管理两个节点之间的自动复制，并提供一个高可用性的服务级别协议。
高级缓存除了拥有更强大的性能之外，还提供了众多标准和基本层级不支持的功能，比如VNET集成，Redis群集模式，sharding等
当然除了功能之外，各个层级都有不同的性能指标，允许的客户端最大连接数量也是不同的
比如
| 基本 | 标准
| 高级
|
内存大小
| 250 MB - 53 GB | 250 MB - 53 GB | 6 GB - 530 GB* |
| 网络性能 | 低 - 高 | 低 - 高 | 中等 - 最高 |
客户端最大连接数量
| 20000
| 20000 | 40000 |
当然每个层级也会有不同的登记，比如标准层级还会细分为C0-C6 7个级别，每个级别的价格和性能都是不一样的，具体可以参考以下网址
https://www.azure.cn/zh-cn/pricing/details/cache/
对于生产环境来说，最少也要使用标准版
以上就是Redis的简单介绍，接下来我们来看下创建Redis过程中的一些配置，以及如何验证Redis是否能正常工作