1.文章详情页面静态化方案

    1. 1.基于数据库查询方案
    2. 用户某一条文章，根据文章的id去查询文章内容表，返回渲染页面
    3. 优点：
    4. * 实现简单
    5. * 保证数据强一致性
    6. 缺点：
    7. * 无法支撑高并发
    9. 2.页面静态化方案
    10. 优点：
    11. * 支撑高并发，高可用
    12. * 页面响应快，用户体验好
    13. 缺点：
    14. * 强一致性较弱，但能够保证最终一致性

    2.freemarker介绍

    1. FreeMarker 是一款 模板引擎： 即一种基于模板和要改变的数据， 
    2. 并用来生成输出文本(HTML网页，电子邮件，配置文件，源代码等)的通用工具。 
    3. 它不是面向最终用户的，而是一个Java类库，是一款程序员可以嵌入他们所开发产品的组件。
    5. 模板编写为FreeMarker Template Language (FTL)。它是简单的，专用的语言， 
    6. 不是像PHP那样成熟的编程语言。 那就意味着要准备数据在真实编程语言中来显示，
    7. 比如数据库查询和业务运算， 之后模板显示已经准备好的数据。
    8. 在模板中，你可以专注于如何展现数据， 而在模板之外可以专注于要展示什么数据。

    3.基于redis实现用户关注和取关功能

    1. 一个用户关注了作者，作者是由用户实名认证以后开通的作者权限，才有了作者信息，
    2. 作者肯定是app中的一个用户。
    4. 从用户的角度出发：一个用户可以关注其他多个作者 —— 我的关注
    6. 从作者的角度出发：一个用户（同是作者）也可以拥有很多个粉丝  —— 我的粉丝

    4.redis常见数据结构
    image.png
    5.redis持久化机制

    1. 持久化是有两种方式的。
    2. 1）RDB：RDB 持久化机制，是对 Redis 中的数据执行周期性的持久化。
    3. 2）AOF：AOF 机制对每条写入命令作为日志，以 append-only 的模式写入一个日志文件中，因为这个模式是只追加的方式，所以没有任何磁盘寻址的开销，所以很快，有点像Mysql中的binlog。
    4. 两种方式都可以把Redis内存中的数据持久化到磁盘上，然后再将这些数据备份到别的地方去，RDB更适合做冷备，AOF更适合做热备.
    5. tip：两种机制全部开启的时候，Redis在重启的时候会默认使用AOF去重新构建数据，因为AOF的数据是比RDB更完整的。

    6.redis事务机制

    1. MULTI、EXEC、DISCARD 和 WATCH 命令是 Redis 实现事务的的基础。
    3. Redis 事务的执行过程包含三个步骤：
    5. 开启事务；
    7. 命令入队；
    9. 执行事务或丢弃；
    11. 显式开启一个事务
    13. 客户端通过 MULTI 命令显式地表示开启一个事务，随后的命令将排队缓存，并不会实际执行。
    15. 命令入队
    17. 客户端把事务中的要执行的一系列指令发送到服务端。
    19. 需要注意的是，虽然指令发送到服务端，但是 Redis 实例只是把这一系列指令暂存在一个命令队列中，并不会立刻执行。
    21. 执行事务或丢弃
    23. 客户端向服务端发送提交或者丢弃事务的命令，让 Redis 执行第二步中发送的具体指令或者清空队列命令，放弃执行。
    25. Redis 只需在调用 EXEC 时，即可安排队列命令执行。
    27. 也可通过 DISCARD 丢弃第二步中保存在队列中的命令。
    29. 正常执行
    30. 通过 MULTI 和 EXEC 执行一个事务过程：
    31. ## 开启事务
    32. > MULTI
    33. OK
    34. ## 开始定义一些列指令
    35. > SET “公众号:码猿技术专栏” "粉丝 100 万"
    36. QUEUED
    37. > SET "order" "30"
    38. QUEUED
    39. > SET "文章数" 666
    40. QUEUED
    41. > GET "文章数"
    42. QUEUED
    43. ## 实际执行事务
    44. > EXEC
    45. 1) OK
    46. 2) OK
    47. 3) OK
    48. 4) "666"
    52. 我们看到每个读写指令执行后的返回结果都是 QUEUED，表示谢谢操作都被暂存到了命令队列，还没有实际执行。
    54. 当执行了 EXEC 命令，就可以看到具体每个指令的响应数据。
    56. 放弃事务
    58. 通过 MULTI 和 DISCARD丢弃队列命令：
    60. ## 初始化订单数
    61. > SET "order:mobile" 100
    62. OK
    63. ## 开启事务
    64. > MULTI
    65. OK
    66. ## 订单 - 1
    67. > DECR "order:mobile"
    68. QUEUED
    69. ## 丢弃丢列命令
    70. > DISCARD
    71. OK
    72. ## 数据没有被修改
    73. > GET "order:mobile"
    74. "100"

    7.redis项目中应用场景

    1. 用于保存关注作者的信息 以及作者的粉丝信息

    8.redis的高可用架构 主从 哨兵 集群

    9.redis中 key过期删除策略

    1. redis实际使用的过期键删除策略是定期删除策略和惰性删除策略：
    3. redis 会将每个设置了过期时间的 key 放入到一个独立的字典中，以后会定时遍历这个字典来删除到期的 key。除了定时遍历之外，它还会使用惰性策略来删除过期的 key，所谓惰性策略就是在客户端访问这个 key 的时候，redis 对 key 的过期时间进行检查，如果过期了就立即删除。定时删除是集中处理，惰性删除是零散处理。
    5. 通过配合使用这两种删除策略，服务器可以很好地合理使用cpu时间和避免浪费内存空间之间取得平衡。

    10.redis中 内存淘汰策略

    1. 长期将Redis作为缓存使用，难免会遇到内存空间存储瓶颈，当Redis内存超出物理内存限制时，内存数据就会与磁盘产生频繁交换，使Redis性能急剧下降。此时如何淘汰无用数据释放空间，存储新数据就变得尤为重要了。
    3. LRU（Least Recently Used）最近最少使用的key予以淘汰，是Redis唯一支持的回收方法
    4. Maxmemory配置指令
    5. maxmemory配置指令用于配置Redis存储数据时指定限制的内存大小。
    7. 设置maxmemory为0代表没有内存限制。对于64位的系统这是个默认值，对于32位的系统默认内存限制为3GB。
    9. 当指定的内存限制大小达到时，需要选择不同的行为，也就是策略。 Redis可以仅仅对命令返回错误，这将使得内存被使用得更多，或者回收一些旧的数据来使得添加数据时可以避免内存限制。
    11. 回收策略
    12. 当maxmemory限制达到的时候Redis会使用的行为由 Redis的maxmemory-policy配置指令来进行配置。
    14. 以下的策略是可用的:
    16. noeviction:是Redis默认内存回收策略，返回错误当内存限制达到并且客户端尝试执行会让更多内存被使用的命令（大部分的写入指令，但DEL和几个例外）
    17. allkeys-lru: 尝试回收最少使用的键（LRU），使得新添加的数据有空间存放。
    18. volatile-lru: 尝试回收最少使用的键（LRU），但仅限于在过期集合的键,使得新添加的数据有空间存放。
    19. allkeys-random: 回收随机的键使得新添加的数据有空间存放。
    20. volatile-random: 回收随机的键使得新添加的数据有空间存放，但仅限于在过期集合的键。
    21. volatile-ttl: 回收在过期集合的键，并且优先回收存活时间（TTL）较短的键,使得新添加的数据有空间存放。