阅读以下关于数据库缓存的叙述，在答题纸上回答问题1至问题3。
[说明]
某互联网文化发展公司因业务发展，需要建立网上社区平台，为用户提供一个对网络文化产品(如互联网小说、电影、漫画等)进行评论、交流的平台。该平台的部分功能如下:
(a)用户帖子的评论计数器;
(b)支持粉丝列表功能;
(c)支持标签管理;
(d)支持共同好友功能等;
(e)提供排名功能，如当天最热前10名帖子排名、热搜榜前5排名等;
(f)用户信息的结构化存储;
(g)提供好友信息的发布/订阅功能。
该系统在性能上需要考虑高性能、高并发，以支持大量用户的同时访问。开发团队经过综合考虑，在数据管理上决定采用Redis+数据库(缓存+数据库)的解决方案。
Redis支持丰富的数据类型，并能够提供--些常见功能需求的解决方案。请选择题干描述的(a)~(g) 功能选项，填入表4-1中(1)~ (5)的空白处。
（1） (a)
（2） (b)、(g)
（3） (c)、(d)
（4） (f)
（5） (e)
（1）(a) 依据：STRING 类型在 Redis 中可用于存储简单的字符串、整数或浮点数 。用户帖子的评论计数器，主要是对整数进行计数操作，利用 STRING 类型的原子自增（INCR）、自减（DECR）等命令，能方便高效地实现评论数量的统计，所以（1）对应 (a) 。
（2）(b)、(g) 对于 (b)：LIST 类型是一个双向链表，可以在链表两端进行插入和删除操作 。粉丝列表功能中，可将粉丝信息按添加顺序依次存储在 LIST 中，能满足粉丝列表这种具有顺序性的数据存储需求，便于按顺序遍历粉丝列表等操作，所以 LIST 可对应 (b) 。有的同学说粉丝要算共同好友怎么办，的确有争议，选 SET也可以，实际还是要看具体的应用场景。针对这题，题干出现列表，我们就选列表，绝对没错。
对于 (g)：好友信息的发布 / 订阅功能，发布的好友信息可按时间顺序等依次存入 LIST 。比如新发布的好友动态可以从链表一端插入，在订阅查看时能按顺序依次获取，符合 LIST 类型顺序存储和操作的特性，因此（2）也对应 (g) 。
（3）(c)、(d)。对于 (c)：SET 类型是无序且不重复的集合。在标签管理功能中，标签集合不需要考虑顺序，且每个标签应该是唯一的，使用 SET 类型可以利用其自动去重特性，方便地实现标签的存储、添加、删除以及判断某个标签是否存在等操作，所以 SET 对应 (c) 。这里标签用顺序是否可以，凯恩认为也可以。题干描述不清楚，留给大家讨论。
对于 (d)：共同好友功能中，共同好友组成的集合不需要有特定顺序，且好友个体不能重复，SET 类型的无序去重特性正好适用于存储共同好友集合，能有效进行共同好友的相关操作，所以 SET 也对应 (d) 。
（4）(f)。依据：HASH 类型是由字段和值组成的键值对集合，适合存储结构化数据。用户信息包含姓名、年龄、联系方式等多个属性，以 HASH 类型存储时，可将用户 ID 作为键，用户各项属性作为字段和对应的值，方便对用户信息的各个属性进行独立的增删改查操作，所以（4）对应 (f) 。
（5）(e)。依据：ZSET 类型是有序集合，每个元素都关联一个分数，Redis 会根据分数对元素进行排序。在提供排名功能（如当天最热前 10 名帖子排名、热搜榜前 5 排名等）中，可将帖子或热搜词条作为元素，将其热度值、搜索次数等作为分数存储在 ZSET 中，通过对分数的排序就能轻松获取排名情况，所以（5）对应 (e) 。