Java之开发 系统设计 分布式 高性能 高可用

1、restful api 基于rest构建的api

        规范：

• post delete put get 增删改查
• 路径 接口命名 
• 过滤信息
• 状态码

2、软件开发流程

3、命名规范 

• 类名：大驼峰
• 方法名：小驼峰
• 成员变量、局部变量：小驼峰
• 测试方法名：蛇形命名 下划线_ 连接，全部小写
• 常量、枚举名称：蛇形命名 全部大写
• 项目文件夹：连接符 -   串式命名
• 包名： 用. 连接
• 抽象类命名：用Abstract开头
• 异常类： 以Exception结尾
• 测试类：以Test结尾

4、重构：提升代码&架构的灵活性/可扩展性以及复用性   重构的最终目标是 提高软件开发速度和质量 。

5、认证授权

• 多服务器节点下session-cookie方案怎么做？ 某个用户的所有请求都通过特性的哈希策略分配给同一服务器处理
• 如何防止CSRF（跨站请求伪造）攻击？使用token，存储在localStorage

6、JWT（json web token）

• 自身包含了身份验证所需要的所有信息，服务器不需要存储session信息，减轻了服务器的压力 
• header  （令牌类型，jwt；签名算法）payload（注册声明） signature（用secret对前两部分进行的签名）
• 用户登录，服务端校验生成JWT，以后每次访问都带上这个JWT，服务端检查JWT并从中获取用户相关的信息
• 为什么没法篡改呢？JWT 安全的核心在于签名，签名安全的核心在密钥
• 优点：无状态、可以防止CSRF攻击、单点登录良好、适合移动端应用
• 缺点：不可控、注销登录等场景下JWT还有效 、续签问题、体积太大
• 解决方案：注销登录等场景下JWT还有效——将JWT存入数据库、黑名单机制
• 续签问题——JWT的有效期一般都建议设置的不太长

7、数据安全

• 哈希算法是一种用数学方法对数据生成一个固定长度的唯一标识的技术，可以用来验证数据的完整性和一致性，常见的哈希算法有 MD、SHA、MAC 等。
• 对称加密算法是一种加密和解密使用同一个密钥的算法，可以用来保护数据的安全性和保密性，常见的对称加密算法有 DES、3DES、AES 等。
• 非对称加密算法是一种加密和解密使用不同的密钥的算法，可以用来实现数据的安全传输和身份认证，常见的非对称加密算法有 RSA、DSA、ECC 等。

8、系统设计

• 具体需求（要实现的功能，指标）——设计——后续优化方向

9、性能指标

• RT 响应时间就是用户发出请求到用户收到系统处理结果所需要的时间。
• 并发数可以简单理解为系统能够同时供多少人访问使用也就是说系统同时能处理的请求数量。
• QPS（Query Per Second） ：服务器每秒可以执行的查询次数；
• TPS（Transaction Per Second） ：服务器每秒处理的事务数
• 吞吐量指的是系统单位时间内系统处理的请求数量
• 高并发简单来说就是能够同时处理很多用户请求。
• 高性能简单来说就是处理用户的请求速度要快。
• 高可用简单来说就是我们的系统要在趋近 100% 的时间内都能正确提供服务。
   

 10、系统活跃度指标

• PV 访问量, 即页面浏览量或点击量
• UV 独立访客，统计1天内访问某站点的用户数。
• DAU 日活跃用户数量
• MAU 月活跃用户数量

11、性能测试软件

• Jmeter：Apache JMeter 是 JAVA 开发的性能测试工具
• ab ：全称为 Apache Bench 。Apache 旗下的一款测试工具，非常实用
   

12、性能优化的方向

SQL优化，JVM、DB，Tomcat参数调优 > 硬件性能优化（内存升级、CPU核心数增加、机械硬盘—>固态硬盘等等）> 业务逻辑优化/缓存 > 读写分离、集群等 > 分库分表
 

13、性能测试分类

• 性能测试
• 负载测试：资源达到上限
• 压力测试:   直到服务器崩溃
• 稳定性测试

14、高可用

黑客、硬件故障、高并发量等

对策：代码质量；集群化；限流；超时和重试机制；熔断机制；异步调用；使用缓存；监控报警；注意备份，必要时回滚；灰度发布；

限流：

简单窗口计数：实现简单 到那时限流速率不够平滑；无法应对激增的流量

滑动窗口计数

Guava 的RateLimiter

redis+Lua 减少网络消耗 保证原子性

超时重试：1500ms  Guava Retrying 

降级：服务降级指的是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面有策略的降级，以此释放服务器资源以保证核心任务的正常运行。

熔断：熔断是应对微服务雪崩效应的一种链路保护机制 A-B-C C出问题 这条路就应该及时断掉

降级的目的在于应对系统自身的故障，而熔断的目的在于应对当前系统依赖的外部系统或者第三方系统的故障。
15、高性能

（1）CDN 内容分发网络 静态资源分发到多个不同的地方以实现就近访问，进而加快静态资源的访问速度，减轻服务器以及带宽的负担。全站加速：既可以加速静态资源又可以加速静态资源

回源——CDN节点上资源没有，从原始服务器获取最新的资源

预热——在CDN上提前将内容缓存到CDN节点上

那怎么知道CDN内容存储在哪里呢？  GSLB 全局负载均衡  CDN 会通过 GSLB 找到最合适的 CDN 节点。

（2）负载均衡 

Nginx

算法：随机法 ；轮询法

怎么做？DNS解析 

反向代理 ：客户端将请求发送到反向代理服务器，由反向代理服务器去选择目标服务器，获取数据后再返回给客户端。对外暴露的是反向代理服务器地址，隐藏了真实服务器 IP 地址。反向代理“代理”的是目标服务器，这一个过程对于客户端而言是透明的。

（3）数据库优化

• 读写分离：将对数据库的读写操作分散到不同的数据库节点上   如何实现？ 代理：MySQL Router  自动分辨对数据库读写操作并把这些操作路由到正确的实例上     组件sharding-jdbc 

主从复制 binlog

主从延迟 等一会再读 或者把压力给到主服务器

• 分库分表 解决MySql 的存储压力                                                                                             单表的数据达到千万级别以上，数据库读写速度比较缓慢。数据库中的数据占用的空间越来 越大，备份时间越来越长。

按照业务垂直分库  水平分库

分表就是对单表的数据进行拆分   垂直分表（按列）水平分表

手动 ShardingSphere 自动TiDB

（4）数据冷热分离 

时间维度、频率维度

冷数据存储方式 中小厂：MySQL/PostgreSQL  大厂：Hbase（常用）

（5）优化SQL

16、设计模式

17、定时

• Timer 单线程 执行这个任务就不能执行其他的了  无法使用cron表达式执行定时任务
• ScheduledThreadPoolExecutor 线程池  无法使用cron表达式执行定时任务
• spring task 是spring提供的，利用@scheduled就可以实现利用cron表达式进行定时任务 但是只适合单机
• 分布式定时框架 XXL-JOB 调度中心和执行器两部分组成。调度中心主要负责任务管理、执行器管理以及日志管理。执行器主要是接收调度信号并处理。另外，调度中心进行任务调度时，是通过自研 RPC 来实现的。 @XXLJOB()
• Redis 和 MQ 虽然可以实现分布式定时任务，但这两者本身不是专门用来做分布式定时任务的，它们并不提供较为完整和强大的分布式定时任务的功能。而且，两者不太适合执行周期性的定时任务，因为它们只能保证消息被消费一次，而不能保证消息被消费多次。因此，它们更适合执行一次性的延时任务，例如订单取消、红包撤回。实际项目中，MQ 延时任务用的更多一些，可以降低业务之间的耦合度。

18、RPC

 RPC 的出现就是为了让你调用远程方法像调用本地方法一样简单

更多用于Client/Server (C/S) 架构   定制化程度高，更简单的保存结构体数据

19、kafka

•  分布式流式处理平台  消息队列  异步 削峰 解耦
• 主要优点：批量处理 异步 生态系统的兼容性
• 发布-订阅模式 都可以订阅消息 
• kafka的
• kafka的多副本机制，其实就是相当于分区的多个副本，有leader，有follower，leader挂了，还有follower，提高了容灾能力
• 多分区的好处：特定的topic有多个分区，各个分区又可以分布在不同的broker上，这样能提供更好的并发能力
• kafka如何保证消息的顺序性：一个topic只对应一个分区  还可以通过设置key保证消息分发到一个分区
• kafka如何保证消息不丢失：消费消息的时候丢失 每次真正消费完消息之后再自己手动提交offset  但是也可能消费完消息了还没手动提交挂了 就会导致消息的重复消费
• 丢失问题：假设leader所在的broker突然挂掉，需要从follower中挑选一个晋升为leader 可以设置acks=all  代表所有的副本接收到消息   设置replication.factor>=3 分区中包含3个以上的副本   min.insync.replicas>1 消息至少被写入2个以上的副本才算的是成功发送
• 消息不重复消费：幂等校验  比如 Redis 的 set、MySQL 的主键等天然的幂等功能
• Kafka 消费者在默认配置下会进行最多 10 次 的重试，每次重试的时间间隔为 0，即立即进行重试。如果在 10 次重试后仍然无法成功消费消息，则不再进行重试，消息将被视为消费失败。
• 消费失败 重试也不能消费的消息会加入到死性队列