基于社区电商场景的Redis缓存架构实战02-社区电商项目实战

025_社区电商的业务闭环知识讲解1

进入我们redis模块项目实战部分去了，前面20多讲，把redis内核级别的知识，做了一个深入的讲解，面试跳槽的时候，如果要是被问到redis，可以主动说，你研究过一些redis比较底层的实现原理，学到的东西说一说，还是挺有优势的

redis 完整的项目实战

基于redis作为主体技术，mysql和rocketmq作为一个辅助和配合，业务闭环的社区电商 社区电商，关键点在于社区->电商辅助性质（次要地位，流量变现），社区，分成很多种社 区，美食社区、美妆社区、影评社区、妈妈社区，社区平台有很多很多，中小型的居多，体育社区、汽车社区、本地生活社区

美食社区APP

大家可以在这个APP里分享自己积累的美食的一些食谱，网上看到的，也可以是自己做菜积累的食谱，食谱自己做菜的过程，分享，图文，视频，主题性质的，你自己对美食的看法，食谱，做菜的过程，出门吃饭体验的一些餐馆和美食，美食科普性，跟美食相关的，你很感兴趣，你积累的一些东西，体验的一些东西，都可以发出来给别人进行分享。这就是非常垂直化的电商APP，只关注与一个领域

浏览别人发出来的一些美食食谱、体验、经历、科普，看别人发的帖子，互动，关注，粉丝， 私信，交流，成为好友，跟平台里的好友，成立一个平台里的私密圈子，基于美食兴趣爱好，进行社交活动

美食社区APP，专门提供给别人来分享、浏览和社交活动，APP没法盈利，在这个里面会有一些人是产出的内容特比的优质，很多人来浏览，粉丝，读者，关注人，分享的东西，浏览量是非常大的，种草，发出来一个美食食谱和做法的帖子，你可以推荐一下某款酱油、某款味精，他的好处和优点，种草APP 提供，浏览你的帖子的人，他看到你推荐的商品，可以点击一个商品链接，直接进入商品详情页里去，浏览一下这个商品介绍，可以把这个商品加入自己的购物车里去，就可以直 接发起交易，完成商品购买。支付钱以后，APP可以找第三方商品提供方来合作，也可以自建仓库， 仓库里可以给你进行商品的发货

社区电商，依赖于社区的，KOL，意见大v他们会有很多粉丝和读者，他们会隆重推荐一下某款商品。用户购买商品支付的钱，会被分成3份，一份是用来商品购买和以及物流发货，一份是给 KOL 大v的，还有一份是给社区电商 APP，平台层面，他也得挣钱，整个业务流程就是这样

026_社区电商的业务闭环知识讲解2

社区电商APP的商业运作模式讲解了，商业模式。feed -> 给一些小动物喂东西吃 / 小婴儿小宝宝喂东西吃 -> 放在技术领域里面，feed流， feed技术，如果我们是一个用户，进入了APP，APP如果要做一个feed行为，他会主动的不停的在APP界面里提供各种各样的内容喂给我们，这就是APP主动feed的过程

feed流，APP不断的主动显示各种新的内容给我们，不断的显示出来的大量的新内容，就是feed 流，feed流特殊的场景和行为，没有feed流的，我们仅了一个APP之后，你想要看什么东西，都得自己主动浏览、自己搜索寻找。一页一页的浏览，浏览的是静态的、不动的内容

商品搜索项目，1亿个商品，我们可以主动搜索和浏览，一页一页的翻过去，我们也在不停的看APP里的内容，你自己主动的行为，内容都是你自己主动去找出来的，浏览出来的。

电商APP，首页，你也没搜索，条件，你就是不停在首页往下拉拉拉，每次拉的时候，电商APP 自己根据你过往的喜好、当前的爆款，算法，不停的显示出来一批新的内容给你看，这种就叫做电 商APP的feed流了。

feed 流，社区电商APP里，进入首页以后不停的拉拉拉，算法把你关注过的大v、可能感兴趣的美食帖子、浏览量高的爆款帖子，不停的计算出来新的一批内容显示给你。

今日头条、百度APP，你可以不停的刷新，不停的刷新，不停的刷新每次刷新，他都会根据算法自动给你推一批内容出来，他不停的喂东西给你，这种就是feed流行为。包括微博，别的社交平台，首页不停的刷新，他就不停的靠算法给你推荐一批一批的内容，这种都是feed流行为

027_社区电商的业务闭环知识讲解3

美食帖子、菜谱帖子，在这个平台里，所有的内容都是用户自己生产的，每个用户在这个里面都可以发布自己的美食分享、菜谱分享，海量内容，基于海量内容，就可以结合算法，不停的在首页推内容给你来看

对美食分享，可以基于条件（板块、分类）+ 分页，分页浏览指定范围的分享帖子，这种就不属于feed流了。这是对你的所有的美食数据，进行结构化的查询和分页浏览

用户在APP上看到的这些东西，都是属于类似于一个一个缩略图+标题，这种都属于是粗浏览，首页 feed 流、分页查询，当你对某个美食分享感兴趣的话，就可以点击进去看详情页，包含了你这次分享所有的内容，包括图文，视频，作者

028_社区电商的流量变现交易闭环讲解

小红书就是社区电商，内部不同的人，美妆达人，发布各种分享帖子，你可以去浏览，在帖子里可 以发评论，收藏，点赞，关注达人，社区电商APP来说，社区社交互动的东西给他做好了之后，APP里会有大量的流量，APP有多少注册用户、每天活跃的用户有多少人，这些都是属于你的平台里的流量

使用你的APP，需要技术团队开发，运营团队推广，客服团队来售后、成本、盈利，应该如何来做呢？引入电商，社区类的APP，最好的模式，种草，平时各种人发布分享的时候，可以在分享内容里插播一些对商品推荐，给出商品的链接

别人在里面浏览分享的时候，看到推荐的商品，链接，点击链接就可以进入商品详情页，商品标题、图文、视频、介绍、价格、营销活动、库存，加入购物车，购物车的多个商品发起一个提交订单，支付，履约拿到商品

029_社区电商的交易和履约闭环讲解

香菇滑鸡的制作帖子，里面有诱人的图片，以及制作的方法和过程，录了视频下来，做的特别好。 -> 推荐， 做出来的菜，为什么这么好吃呢，因为我用了xx品牌的酱油，用了原材料，经过九九八十一道工序来加工制作，倍儿香，如果想要做菜好吃，就用xx酱油 -> 酱油的链接，酱油商品缩略图、商品标题、价格、链接，点击 -> 酱油详情页里，具体介绍，图文+视频，复古工艺， 纯天然的原材料 -> 16.8一瓶，而且有活动买3赠1，干脆就买3瓶酱油得了，还能送一瓶 -> 把这个酱油商品点击加入购物车的按钮里去

030_基于社区电商APP原型图理解业务

具体内容见：/v1.0项目资料/社区电商案例全方案设计.pdf - 2. 1 . 1 ⾸⻚feed流展示菜谱

031_本次社区电商项目实战涉及模块讲解

彻底理解了社区电商业务闭环（社区闭环、电商闭环），完整的东西包含的模块太多了，我们最主要的是涉及到里面核心的模块：

首页feed流架构（只做工程架构，不涉及算法）、美食分享/美食查询浏览/详情页（缓存架构）、分享和活动、商品详情页、商品的库存（基于缓存的企业级）、购物车（基于缓存的企业级）。选择这些模块，围绕我们实战主题来的，redis项目实战

社交互动（点赞/评论/收藏/关注/私信）、交易闭环，这些就不会去涉及和开发了

032_Redis 缓存架构解决方案和生产实战

社区电商业务闭环的开发：首页feed流、美食分享/浏览/详情、社交分享和团购活动、商品详情/库存、购物车，主题都是基于mysql是基础，核心是基于redis开发一套企业级的缓存架构实现，rocketmq也是辅助和配合

基于redis为主体的架构，要上生产的，还需要考虑到各种各样的生产问题，这就需要一整套redis的解决方案， 结合社区电商业务进行落地

热key问题：比较典型的是微博，某个明星突然官宣恋爱/离婚，瞬时大量的人涌入那个明星的微博里去看，瞬时可能几十万百万、千万级的请求打到redis里一个节点中的一个key，这就是热key问题

对于我们来说，热key的情况，如果说我们要是有一个比较好的美食分享和团购活动，可能短时间内引发了大量的人把这个美食分享的详情页，给分享到了大量的微信社群、朋友圈里去，短时间内引发大量的人看一个美食分享的详情页，造成redis的热key出现

大value问题：存储的key对应的value特别的大，value多达10mb，这个value如果被读取的频繁一些，就可能会把你的网络带宽给打满，就会导致你别的请求会被阻塞。

如果说遇到了一些问题，某个数据因为各种原因，在缓存里就是查不到，短时间内有很多请求，都穿透到mysql层面去了，此时穿透问题如何处理；

缓存的过期和失效，缓存数据设置了过期的时间，到期失效了以后应该如何来处理

redis如果内存满了，LRU 算法自动淘汰了一些数据，对于这些数据我们应该如何进行处理

redis 集群都崩溃掉了，只有数据库可以访问，这个时候就需要自动识别缓存故障，立马进行限流，对数据库进行保护和防护，让数据库不要崩溃掉。另外立即启动各个接口的降级机制，各个接口，都可以提前在jvm内存缓存里，保存一些少量缓存作为降级备用数据，redis崩了以后，就去查 mysql，限流 -> 降级 -> jvm内存里缓存的默认数据来提供给用户 -> 降级以后的提醒也可以，每个接口都需要有一个降级方案

缓存数据和数据库之间的一致性的保障，双写、异步同步。异步同步如何保证一致性

redis 解决方案：结合业务场景落地，热key和大value，就是比如某个key形成了热点，还 有大value，缓存穿透、失效和LRU被清理 -> 缓存自动加载和重建、雪崩（缓存一旦故障， 自动限流避免数据库被打死）、和数据库的一致性保障

redis 生产实战：上了生产以后，就是模拟出足量的数据灌入redis里，因为都是社区里的人 自发发的这种，可以给大量的数据，比如redis集群部署、然后千万级数据量放redis里，然后就是高并发压测，cachecloud监控运维，可以看到多少个缓存节点、里面放了多少GB的数据、每个节点多少GB、大压力下接口性能如何、QPS多少、redis机器负载如何、缓存命中率如何、数据库回源比例是多少、再就是一些运维，比如redis节点故障的主从切换演示， redis集群扩容演示

033_基于数据库与缓存双写的美食分享功能

业务闭环开发过程中，会大量的运用到我们的redis缓存架构。cookbook就是菜谱/美食分享，美食、标题、介绍、做法、原材料、视频，社交互动，商品种草，社交分享和团购活动

发表一次美食分享、对应代码里的cookbook菜谱创建接口，美食分享都是有一个作者userId，在你发表美食分享之前，你自己作为一个 用户就得先注册和登录到APP里去，你发表的时候，你自己的账号id，就是你的美食分享的userid

平台来说，有的可能是一些个人用户发表的分享，也有的可能是专业的机构/公司，他们有很强的原创美食内容的生产能力，组成了一个公司，专门在各个平台里发布美食类的原创内容，吸引粉丝，自己的内容流量足够大的时候，就可以开始种草->卖商品->流量变现，各个平台里都是很典型的一种商业模式，任何普通人和任何专业公司，注册到平台之后，都可以在这里发表美食分享

034_社区电商APP用户管理功能实现

美食分享核心数据模型 -> 要发表美食分享 -> userid -> 作者 -> 美食电商 APP 用户管 理功能，用户注册、登录 -> 模拟接口，接口可以加入一个社区电商APP的用户

把我们的社区电商APP用户数据在redis缓存里去写一份，并生成随机的过期时间，把用户数据写入到缓存里去，每条用户数据都会在redis里缓存个2天+随机个几个小时的过期时间。用户数据后续高并发读取的时候，就是可以直接从缓存里提取用户数据，用户数据一般是不会变化的。

第一次注册，偶尔修改，写少读多，写0.01%，读99.99%，非常适合用缓存来支持用户数据高并发。设置过期时间，用户数据可能不是说经常会被读取的，有些用户是冷门个人用户，他发表的东西，一般不会有人经常看。默认来说，2天多过期掉，如果后面有人要访问，缓存里没找到数据，从库里加载出来写缓存就可以了。如果经常会读某个用户，则可以不断的延长他的过期时间

同时这个线程在这里，把新数据写入了redis缓存里，此时我认为没问题的，缓存是最新的

035_热门用户数据的缓存自动延期机制

用户数据是写少读多的场景，对用户数据在创建时时候做一下缓存是非常合适的，在各种场景下，读取用户数据就直接从缓存里加载，埋了一个伏笔，用户数据在缓存的时候，过期时间，随机的2天多的时间

少数的用户是热门的，他发表的分享是很多人会看到的，大部分用户他的用数据是冷数据， 一般都没什么人会去care他们发表的内容，没有必要说让所有的用户数据都驻留在缓存里， 占用缓存宝贵的内存空间。没什么人访问这个用户数据，让他默认过期掉就可以了，后续如果真有访问，从数据库里回源，写入到缓存里就可以了；

热门用户数据来说，很多人去访问，每次访问用户数据，我们做一个机制，缓存自动延期设计，过期时间都会延长上一次写入数据：1月1号，expireTime=1月3号，到1月3号有人访问了他，过期延期， 1 月5号，下次在2天多内有人来访问，几乎一直可以从缓存里加载到用户数据，热门据基本都可以从缓存来读取，实现高并发读

冷门的用户数，如果连续2天多没人读取他，expire过期掉了，只能从db里读取，回源数据库里读取，读取完毕了以后，还要再次写入缓存里去

代码地址：E:\儒猿课堂\Redis\4.模块四 基于社区电商场景的Redis缓存架构实战_1- 架构\资料\v1.0项目资料\careerplan-eshop-redis