消息队列数据存储采用了主从架构的MySQL表格。消息队列有多个分组，在分组内，有主服务器负责读写请求；有从服务器负责读请求。消息队列的主服务器对应一个MySQL的主服务器，消息队列的从服务器对应一个MySQL的从服务器。
表格名称：使用{分组名称}_{队列名称}作为表格名称，每个分组一张表。原因是数据是分组的，MySQL的主服务器可以进行写入。如果采用每个分组一张表，不同组间互不影响；如果采用所有队列一张表，写入的同步比较复杂。
| 字段 | 索引 |
| 消息ID | 是。因为是主键，自然是索引。 |
| 队列主题 | 是。可以方便找到同一队列的所有消息 |
| 消息内容 | |
| 分片标识 | |
| 生成的时间戳 | |
| 生产者ID | |
| 消息状态 |
核心业务：登录，充值，购买商品
用户ID：全局唯一的，不可修改
用户余额：不可丢失，全局强一致性
充值记录：ID全局唯一，充值记录只能新增，不可修改
英雄和皮肤订单：同样的英雄和皮肤只能购买一次，不可丢失，全局强一致性。
鲜花等道具：订单记录只能新增，不可修改，可重复
用户ID由于全局唯一且不可修改，符合幂等性。可以采用数据库同步+消息队列同步。
用户余额可采用数据库同步。
充值记录可采用数据库同步。
英雄和皮肤订单采用数据库同步，与实物电商不同，不需要考虑库存的问题（无需库存拆分）。
鲜花等道具订单可以用存储系统同步，与实物电商不同，不需要考虑库存的问题（无需库存拆分）。
微信钱包或者QQ钱包无法登录/授权，只能容忍通告暂时无法充值。
充值记录没有同步，可以暂时容忍，等待记录同步并更新余额。
如果由于在不同服务器上购买同样的英雄和皮肤，当数据库同步的时候，需要退还点券，并合并英雄/皮肤。如果在一台服务器上购买了，在另外一台服务器上看不到，只能暂时容忍，等待合并。
购买鲜花等道具，没有及时同步。只能暂时容忍，等待数据同步。
【背景】
假设你现在是一个创业公司的 CTO，开发团队大约30人左右，包括5个前端和25个后端，后端开发人员 全部都是 Java，现在你们准备从0开始做一个小程序电商业务，请你设计微服务拆分的架构以及微服务 基础设施选型。
【作业要求】
【提示】
1. 需要应用三个火枪手原则; 2. 需要选择拆分方式;
3. 需要选择微服务框架的模式。
由于是创业公司的新项目，在没有业务专家的情况下，可以参考已有的电商系统实现采用一步到位的模式。后端开发人员25，根据三个火枪手的原则，拆分为8个模块：用户，商品，订单，支付，物流，店铺，结算，统计。由于电商服务和业务流程强相关，可采用按业务拆分。
拆分后的架构图如下：
由于技术栈采用统一的Java，且前期的业务量不大，可以采用架构简单，维护简单的嵌入SDK模式。可以考虑使用Spring boot框架，搭建微服务的框架。
日活2.5亿，平均每人日发一条，共2.5亿条。60%集中在四个小时发送，平均TPS 为：
2.5 亿*0.6/(3600*4) =10K/s
平均一条微博100次观看，且活跃时间与发微博相同。平均QPS为：
10K/s*100 = 1000K/s
平均一条微博5条评论，且活跃时间与发微博相同。平均TPS为：
10K/s*5= 50K/s
平均一条微博评论10次观看，且活跃时间与发微博相同。平均QPS为：
50K/s*10=500K/s
发评论是写操作，因此不能用缓存，可以用负载均衡。实时性要求不高，可以考虑用消息队列进行缓冲。
看评论是读操作，由于发了评论不能修改，适合用缓存架构。由于请求量大，负载均衡也需要。
负载均衡的算法：
发评论和看评论在任何服务器上都可以，简单选择“轮询”或者“随机”算法。
看评论缓存：
采用与看微博类似的CDN能承载90%的用户流量。使得看评论的QPS只有10%，也就是50K/s进入系统。
业务服务器数量估算：
发评论与发微博类似，涉及内容审核，数据写入存储，数据写入缓存，因此按照一个服务器每秒处理500来估算，完成50K/s的TPS，需要100台服务器，加上一定的预留量，120台服务器差不多了。
看评论除去CDN的流量，50K/s进入系统。由于读评论逻辑简单，主要是读缓存系统，假设单台服务器处理能力是1000/s，机器数量为50台，加上20%的预留量，60台服务器差不多了。
4级负载均衡架构
缓存采用多级缓存架构，包括APP/浏览器缓存，CDN缓存，WEB容器缓存，进程内缓存，分布式缓存。 由于评论发了之后不能更改，以及时间局部性，进程内缓存不会造成一致性的问题，并且可以大大降低对于数据库，文件/对象存储的读取请求。
发评论的重要性和影响力都不如原微博。可以考虑对“发评论”限流。可以采用消息队列配合“漏桶算法”，对于发评论进行异步写入，从而降低瞬时的TPS
看评论可以采用“多副本缓存”降低缓存热点的问题。
假设每门课2次考试，每个学生每学期20门课。
假设学校考试都在一个月内，考试集中在上午4小时和下午4小时。请求试卷集中在考试前的一分钟，提交答案集中在考试开始前的一分钟，提交答案集中在考试结束前30分钟。
采用Redis sentinel来存储试卷。
技术本质：
试卷读取的数据结构：
试卷提交的数据结构：
教师登陆系统 => 向课程考试子系统发起创建试卷请求 => 获取试卷ID并将其写入课程考试系统的SQL表中 => 教师提交试卷的内容给课程考试子系统 => 课程考试子系统将 key（学校ID + 课程ID + 试卷ID） + value（试卷内容）写入Redis
学生登陆系统 => 向课程考试子系统发起获取试卷请求 => 课程考试子系统查验学生信息及考试开始时间 => 课程考试子系统生成 key（学校ID + 课程ID + 试卷ID）=> 向Redis发送请求 => 获得试卷并返回
由于同时拉取同一份试卷的人数很多，可以在server端缓存试卷内容。这可以进一步降低Redis的读取负载。
学生登陆系统 => 向课程考试系统发起提交试卷请求 => 课程考试系统将生成Key（学校ID + 课程ID + 试卷ID + 学生ID）写入SQL表中 =>课程考试系统将key（学校ID + 课程ID + 试卷ID + 学生ID）+ value（考试答案）写入Redis
教师登陆系统 => 向课程考试子系统发起批改试卷请求 => 获取该门课程学生的ID => 生成范围查询向Redis发起读请求 => 查阅试卷 => 向课程考试子系统发起请求更新分数
单机Redis的QPS约为5-10W/s。 读取试卷的峰值QPS约为5W/s。使用单台主机，两台从机就可以了。因为试卷内容提交之后就不变了，两台从机除了可以冗余备份，还可以分担读取的压力且没有数据延迟的问题。三台Redis应付读取试卷的峰值QPS绰绰有余。在两台Redis服务器损坏的极端情况下，也能满足试卷峰值读取的QPS。
Redis的Sentinel可以采用一主两从的模式来保证数据的高可用，并在单点故障下自动切换。
本文是外包学生管理系统详细架构设计文档，用于指导学生管理系统的开发，测试和运维。
基于学生数量和需要管理的数据的增加，线上管理系统成为必要。该系统将要解决的问题有：
分析一下微信朋友圈的高性能复杂度
【作业要求】
【提示】
1. 分析过程可以参考模块2第5课的实战案例，但是不需要将分析过程一一列举出来。
2. 如果某个地方被卡主了，请及时联系助教或者老师讨论。
设计考虑：
2. “学生管理系统”毕设架构设计
假设今年学校毕业设计要求提升，要求做真正可运行的学生管理系统，学院对毕设的具体要求如下:
1 要求可以通过公网域名访问;
2 要求至少3人合作完成;
3 能够支撑管理1000个学生;
4 答辩的时候会根据架构方案来进行打分，不推荐太简单和太复杂的方案。
你找了 2 个好朋友一起来做这个项目，你们的基本情况如下:
1 大家都会Java，但是有一个是PHP高手;
2 大家经济条件一般。
作业要求:
1 对照面向复杂度架构设计方法论，构思2个以上的备选架构方案。 2 使用PPT来画出你的备选架构方案，并说明方案的优缺点。3 给出你选择的最终方案以及选择理由。
方案一：
优点：
缺点：
方案二：
优点：
缺点：
两种方案比较类似。区别主要是：方案一用的单一系统，统一部署。在系统内部用几个模块来实现多个业务；方案二用的是三套子系统，分别部署。最终，我选择方案二。原因是：1. 多个子系统可以并行开发，独立测试。有利于提升开发效率，并能根据开发进度，灵活调整子系统的技术栈选型（JAVA或者PHP）。2. 可以有效利用PHP高手的技术特长。
Wanderful.io has published a chatbot, who can chat with you and help you find apartments in San Francisco and Bay area. Check it out: http://m.me/wanderful.io
Find an interesting website to find apartment and roommates in the Bay Area and San Francisco:
See more:
askmecode 