设计一个系统

在设计系统时，要使用到抽象思想、模块化思想。在分析系统、设计系统架构时，大多情况下都会遵循一个规律：

1. 分析问题特点。可以从用户使用场景角度去分析，主要从流量大小、服务场景的运行时长、资源是否有限；
2. 给出评判标准。可以从用例图的角度去分析，主要包括 C 端用户、平台、B 端用户；
3. 提出解决方案。可以从项目部署视图的角度去分析，主要包括客户端、中间件、服务端；

包括软件设计中的相关概念 软件质量评估与保证、软件开发模式、软件过程控制、软件架构设计

系统设计类

手写 RPC 框架

• RPC 选型
  • 阿里 Dubbo
  • 新浪 Motan
  • Facebook Thrift
  • Google gRPC
• RPC 与 HTTPClient 区别
• 设计自己的 RPC 框架
  • RPC 框架及原理
  • 设计自己的 RPC 框架需要考虑的要点
    • 注册中心
    • 序列化与反序列化
    • 负载均衡
    • 网络传输
    • 动态代理
    • 传输协议
  • 相关技术的选型

如何设计一个排行榜

• 使用 Mysql 的 order by 进行排序
• 使用 redis 的 zset 进行排序

如何设计秒杀系统

• 秒杀系统所具有的特点
  • 技术角度
    • 三高
    • 数据强一致性
    • 读多写少
  • 业务角度
    • 高风险
    • 高利润
• 秒杀系统所遇到的挑战
  • 热点数据的存储
    • 如何探测热点 key：
      • 客户端收集上报：改动 Redis SDK，记录每个请求，定时把收集到的数据上报，然后由一个统一的服务进行聚合计算。方案直观简单，但没法适应多语言架构，一方面多语言 SDK 对齐是个问题，另外一方面后期 SDK 的维护升级会面临比较大的困难，成本很高。
      • 代理层收集上报：如果所有的 Redis 请求都经过代理的话，可以考虑改动 Proxy 代码进行收集，思路与客户端基本类似。该方案对使用方完全透明，能够解决客户端 SDK 的语言异构和版本升级问题，不过开发成本会比客户端高些。
      • Redis 数据定时扫描：Redis 在 4.0 版本之后添加了 hotkeys 查找特性，可以直接利用 redis-cli --hotkeys 获取当前 keyspace 的热点 key，实现上是通过 scan + object freq 完成的。该方案无需二次开发，能够直接利用现成的工具，但由于需要扫描整个 keyspace，实时性上比较差，另外扫描耗时与 key 的数量正相关，如果 key 的数量比较多，耗时可能会非常长。
      • Redis 节点抓包解析：在可能存在热 key 的节点上(流量倾斜判断)，通过 tcpdump 抓取一段时间内的流量并上报，然后由一个外部的程序进行解析、聚合和计算。该方案无需侵入现有的 SDK 或者 Proxy 中间件，开发维护成本可控，但也存在缺点的，具体是热 key 节点的网络流量和系统负载已经比较高了，抓包可能会情况进一步恶化。
    • 如何处理热点 key： 本地缓存+分布式缓存
  • 流量打散
    • 前端如何做？
      • CND
      • 秒杀时添加 验证码 和 回答问题等
    • 后端如何做？
      • 负载均衡，如 nginx
      • 限流器，如 hystrix 和 Sentinel、漏桶算法等
      • 排队处理，如添加消息中间件等
  • 超卖，接口幂等性
    • 分布式锁
    • 同步锁
    • 业务唯一性字段的校验等
  • 预防黄牛和秒杀器
    • 如何识别黄牛和秒杀器？
    • 风险监控系统
  • 服务隔离
    • 熔断：针对服务外部及第三方服务的故障，防止服务调用者由于被调用者的不可用导致的级联故障，服务雪崩
    • 降级：针对服务内部故障
  • 数据强一致性
    • 哪些地方不一致？（数据库和缓存、本地缓存与分布式缓存）
    • 分布式事务（CAP/BASE 原理，分布式事务实现）
  • 性能测试
    • jmeter
  • 服务监控与风险控制
    • 日志搜索平台搭建及链路追踪
    • 封控系统搭建
• 什么是秒杀系统
  • 大量请求对有限资源的瞬时请求
• 秒杀系统的分类
  • 商家为了营销而主动发起供用户争抢某种有限资源的秒杀，称为主动秒杀；
  • 因供需关系紧张而造成的由用户发起，平台被动承担争抢过程的秒杀，称为被动秒杀；
• 秒杀系统的特点（分析问题，是什么）
  • 瞬时的大量请求
  • 三高
  • 读多写少
  • 数据强一致性
• 秒杀系统的主要目标（制定评判标准，为什么）
  • 分析了秒杀系统有什么特点后，并针对每一个特点提供了解决方案后，要检测秒杀系统设计是否满足需求，需要给设计的系统制定一个评判标准，这就是主要目标；
  • 从使用与被使用关系上，可以把秒杀系统分为三个部分：C 端用户、平台、B 端用户；C 端用户使用平台，B 端用户使用平台，平台服务于 C 端用户和 B 端用户
  • C 端用户目标：保障用户体验，包括页面是否流畅、数据是否无误；
  • B 端用户目标：保障用户商品购买时不出错，包括价格、数量、资金等各方面的数据无误；
  • 平台目标：保障 C 端用户和 B 端用户完成用户目标，包括其他相关业务不会收到秒杀系统模块的牵连；
• 解决方案的主要思路（解决方案，怎么样）
  • 分析了实施秒杀系统需要完成的目标后，就需要进行方案的落地，这是回答怎么样的问题；从后期项目的部署视图上，可以把秒杀系统分为三部分：客户端、中间件、服务端；客户端需要服务端提供服务，中间件为服务端提供更好的业务支撑；
  • 客户端：保证资源加载速度、打散流量；可以采用 CND 的技术来保证就近提供服务，可以采用验证码、滑块、问答等方式打散流量；
  • 中间件：对服务端提供稳定、可靠的服务；
  • 服务端：保证高可用、

包括软件设计中的相关概念 软件质量评估与保证、软件开发模式、软件过程控制、软件架构设计