提取码：600x
服务器架构图：
说明：
场景中的这些业务基本是用户进入APP后会操作到的，除了活动日(618,双11，等)，这些业务的用户量都不会高聚集，同时这些业务相关的表都是大数据表，业务多是查询操作，所以我们需要减少用户直接命中DB的查询；优先查询缓存，如果缓存不存在，再进行DB查询，将查询结果缓存起来。
更新用户相关缓存需要分布式存储，比如使用用户ID进行hash分组，把用户分布到不同的缓存中，这样一个缓存集合的总量不会很大，不会影响查询效率。
方案如：
用户签到获取积分 计算出用户分布的key,redis hash中查找用户今日签到信息 如果查询到签到信息，返回签到信息 如果没有查询到，DB查询今日是否签到过，如果有签到过，就把签到信息同步redis缓存。 如果DB中也没有查询到今日的签到记录，就进行签到逻辑，操作DB添加今日签到记录，添加签到积分(这整个DB操作是一个事务) 缓存签到信息到redis，返回签到信息 注意这里会有并发情况下的逻辑问题，如：一天签到多次，发放多次积分给用户。
用户订单
这里我们只缓存用户第一页的订单信息，一页40条数据，用户一般也只会看第一页的订单数据
用户访问订单列表，如果是第一页读缓存，如果不是读DB
计算出用户分布的key,redis hash中查找用户订单信息
如果查询到用户订单信息，返回订单信息
如果不存在就进行DB查询第一页的订单数据，然后缓存redis，返回订单信息
用户中心
计算出用户分布的key,redis hash中查找用户订单信息
如果查询到用户信息，返回用户信息
如果不存在进行用户DB查询，然后缓存redis，返回用户信息
其他业务
上面例子多是针对用户存储缓存，如果是公用的缓存数据需要注意一些问题，如下
注意公用的缓存数据需要考虑并发下的可能会导致大量命中DB查询，可以使用管理后台更新缓存，或者DB查询的锁住操作。
我就根据这个网上的一些博客呀、视频呀，然后自己整理出一套笔记来，然后我还要做课件儿，我还要录视频。 我看一下一个月的时间能不能学会这门新的语言，提前说一下，我仅仅是为了实验尝试看一下入门语一门语言到底有多难，需要多长的时间。 然后，我之前也根本没有接触过这个go语言，好吧，我想可能一个月后我入门了，我可能再来学习一下。 比如说构建一个网站呀，然后这个构语我看还能写一些智能合约发行，甚至来说发行一些这个虚拟货币，我到时候发行一个原动力币哈，都是有可能的。 然后你可能觉得现在这个这个太太先进了吧。 这个东西我告诉你一点都不前进，现在这个区块链的发展已经很成熟了，现在都有一个所谓web3已经出现了。 好，所以说第三点，我就想说，咱们的粉丝朋友们，大家都可以跟着我一点一点学习，都是免费的。 可以加入我的这个粉丝群，群号放在了评论区，我学多少，我就会录制多少的视频。
