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
036_缓存惊群与穿透问题的解决方案
用户数据写入和查询，缓存设计，写入的时候，库+缓存，双写，缓存默认2天多随机时间 的过期，读的时候因为有读延期机制，如果频繁的读，缓存会不停的延期。没有人查呢，会过期从而避免占用缓存的空间，缓存没查到，从数据库里提出来，放到缓存里去
每次写入缓存的时候，为什么一定要设置2天+随机几个小时的时间呢？ 答案是为了解决缓存惊群的问题，缓存一批数据同时过期，突然之间一起都没了，过期时间设置的都是一样的，这就是缓存集群都惊了，数据库也惊了，大量缓存同时过期->惊群 ->瞬时大量请求走到mysql，造成压力
解决方案：大量的缓存数据，过期时间都是随机，不要集中在某个时间点一起过期
惊群，典型的术语，突然在某个时间点，出了一个故障，一大片范围线程/进程/机器， 都同时被惊动了，惊群效应
缓存穿透的一个问题，穿透->读取缓存没读到->从db里读->db也没读到->程序bug或者被外部攻击->高并发的读一个数据，缓存和db都没有->每次高并发读取，缓存都会被穿透过去，每次都要读一下db，导致高并发空请求都针对db在走，造成db压力
缓存穿透是指查询一个不存在的key，由于缓存中没有数据，因此会直接查询数据库。如果每次都查询一个不存在的key，那么会导致大量的请求直接到达数据库，从而导致数据库繁忙，甚至宕机的情况。下面是几种避免缓存穿透的方式： 1、布隆过滤器：将所有可能的查询key哈希到一个足够大的bitmap中，如果某个key对应的bitmap值为0，则该key不存在，直接返回；否则可能存在，再进行进一步查询。 2、缓存空对象：对于那些在数据库中不存在的key，在缓存中也缓存一个空对象，这样就不会频繁地查询数据库。 3、设置过期时间：对于查询数据库中不存在的key，在缓存中设置一个较短的过期时间，这样可以避免在一段时间内频繁地查询数据库。 4、熔断器：在缓存中未命中的情况下，可以启动熔断器，暂时停止对该key的请求，直到缓存中有了数据再恢复请求。 为了避免缓存穿透，可以采取多种措施，需要根据实际情况选择适合自己业务场景的方案。
037_基于分布式锁的缓存+数据库双写一致性
缓存+数据库双写的时候，保证一致性，应该如何来确保？他们的一致性，考虑他们如果不一致，是一个什么样的场景？
写缓存可能是在两个场景里发生：第一个是，纯数据库+缓存的双写，也就是用户注册或者用户信息修改时，会同时写数据库和缓存；第二个是，读取用户信息的时候，如果说缓存没读到，就会 读库，读完库再写缓存；
写缓存是两个场景，这两个场景可能并发的产生。那么可能线程B过来，刚好缓存过期，线程B从数据库中读出用户姓名为张三，在准备将张三写入缓存时发生线程切换，此时线程A过来修改用户信息，将用户姓名从张三换成了张小三，并将张小三同时写入了数据库和缓存，最后线程B苏醒过来，又会将旧的“张三”写入缓存，从而覆盖新的“张小三”数据，从而造成数据库和缓存的不一致
这里也得出一个结论，分析并发数据的不一致性时，一定要分析修改数据有哪些源头，比如上面修改缓存就有两个场景，就从两个场景并发执行去分析可能引起数据不一致的情况
038_基于分布式锁的缓存+数据库双写一致性
写缓存 有一个简单易行的方案，读和写，必须是串行化的，经典方案，加分布式锁
用户数据，0.01%是写，99.99%是读，用户注册和信息更新，操作是极为极为少的，平时大部分都是对用户数据做一个查询，美食分享的详情页里，feed流页面，美食分享要查询你的用户信息，比如作者名称
039_缓存+数据库双写分布式锁高并发优化
不知道为什么，可能我们某个作者平时是很冷门的，用户数据早就过期了，突然之间火了， 一瞬间涌入了大量的人来查询他，从而高并发的读已过期的缓存，大量的线程都没从redis中读到谁，从而导致大量的线程都涌入了load db+write redis 这个getUserInfoFromDB()方法里面
上面132行的代码，分布式获取锁的方法，是没有加超时时间的