Java后端常见场景业务问题

单点登录如何实现

单点登录的英文名叫做：Single Sign On（简称SSO）,只要登录一次，就可以访问所有信任的应用系统。在以前的时候，一般我们就单系统，所有的功能都在同一个系统上，可以使用session共享将用户信息保存在Session对象中。后来，我们为了合理利用资源和降低耦合性，于是把单系统拆分成多个子系统。多系统即可能有多个Tomcat，而Session是依赖当前系统的Tomcat，所以系统A的Session和系统B的Session是不共享的。解决系统之间Session不共享问题有以下几种方案：

• Tomcat集群Session全局复制（最多支持5台tomcat，不推荐使用）
• JWT(常见)
• Oauth2
• CAS
• 自己实现（redis+token）

JWT参考这篇博客。使用jwt解决单点登录的流程如下：

扫码登录如何实现

扫码登录本质就是通过已经登录过的APP应用去扫描未登录的Web端的二维码，通过某种机制来触发登录凭证的写入，从而去实现Web端的自动登录这样一个过程。
首先要在网页端打开登录的页面展示一个二维码，这个二维码里有个服务端生成的唯一编号，然后浏览器会去定时轮询这个二维码的状态，然后在APP端去扫描二维码，把APP端的token信息二维码ID发送到服务端，服务店接收到请求后会去修改二维码的扫描状态，并生成一个临时的token给APP端，这个时候网页端展示的二维码状态会提示已扫描待确认，而APP端去扫码后会给用户一个确认授权的一个操作按钮，点击确认以后携带临时token到服务端，然后服务端再次修改二维码的扫码状态，并且为网页端生成授权token，最后网页端轮询到状态变化，并获取到token从而完成扫码授权。
整个过程并不难，核心设计就是一个特定的二维码去连接APP端和网页端

权限认证如何实现

后台的管理系统，更注重权限控制，最常见的就是RBAC模型来指导实现权限RBAC(Role-Based Access Control)基于角色的访问控制

• 3个基础部分组成：用户、角色、权限
• 具体实现
• • 5张表（用户表、角色表、权限表、用户角色中间表、角色权限中间表）
• • 7张表（用户表、角色表、权限表、菜单表、用户角色中间表、角色权限中间表、权限菜单中间表）

最常见的5张表的关系:

数据流转流程：

张三登录系统—> 查询张三拥有的角色列表—>再根据角色查询拥有的权限

在实际的开发中，也会使用权限框架完成权限功能的实现，并且设置多种粒度，常见的框架有：

• Spring security（推荐）
• Apache shiro

金额用Long还是Bigdecimal？

首先double和float肯定排除，因为它们底层会采用科学计数法，即转换成二进制进行计算，从而导致小数点无限位的问题进而精度丢失。

Long类型在存储的时候，比如要保留小数点到分，那么存储的时候乘以100，取的时候除以100以达到效果。本质上还是一样，只不过long属于隐式小数点，而Bigdecimal属于显示小数点。

我们之前的项目因为只需要保留到分所以使用Long，但是如果项目对精确位数有要求，还是推荐在代码层面统一的使用Bigdecimal，这样方便我们进行计算，然后存储的时候用long会节省内存一点，但也是视情况而定，如果精确的位数要求特别高，那么long类型每次都要乘以很大的数，存储性能也就荡然无存了。所以如果在需求阶段无法确认小数点后面的位数或者要求小数点后面位数较多那么就用Bigdecimal来表示金额。

BigDecimal 是 Java 中一个用于处理任意精度的浮点数类，定义在 java.math 包中。与基本数据类型（如 float 和 double）相比，BigDecimal 主要用于解决由于浮点数精度问题而引起的计算不准确的问题。它特别适合于金融计算和需要高精确度的场景。
主要特点：
1.任意精度：BigDecimal 可以表示任意大小和精度的数字，允许你进行高精度的计算。
2.避免精度问题：使用 BigDecimal 可以避免浮点数在四舍五入和精度丢失方面常见的问题。
3.不可变性：BigDecimal 对象是不可变的，这意味着一旦创建，值就不能被改变。每次进行运算时，会返回一个新的 BigDecimal 对象。
4.支持四舍五入：提供了多种四舍五入策略，适合不同的应用场景。

上传数据的安全性如何保证

浏览器访问后台，需要经过网络传输，有可能会出现安全的问题。解决方案：使用非对称加密（或对称加密），给前端一个公钥让他把数据加密后传到后台，后台负责解密后处理数据

对称加密 文件加密和解密使用相同的密钥，即加密密钥也可以用作解密密钥

优点: 对称加密算法的优点是算法公开、计算量小、加密速度快、加密效率高。
缺点: 没有非对称加密安全.
用途： 一般用于保存用户手机号、身份证等敏感但能解密的信息。

常见的对称加密算法有: AES、DES、3DES、Blowfish、IDEA、RC4、RC5、RC6、HS256

非对称加密 两个密钥：公开密钥（publickey）和私有密钥，公有密钥加密，私有密钥解密。私钥隐秘保存，公钥可以下发给信任客户端.

优点: 非对称加密与对称加密相比，其安全性更好；
缺点: 非对称加密的缺点是加密和解密花费时间长、速度慢，只适合对少量数据进行加密。
用途： 一般用于签名和认证。私钥服务器保存, 用来加密, 公钥客户拿着用于对于令牌或者签名的解密或者校验使用.

常见的非对称加密算法有： RSA、DSA（数字签名用）、ECC（移动设备用）、RS256 (采用SHA-256 的 RSA 签名)

订单表每天新增500W数据，分库分表的方案应该如何设计？

分库分表的方案 要避免分好之后又出现容量满的情况或者单表数据过大的问题，这个时候再去做容量扩充那么数据迁移和扩容的成本会很高。

一天500w，那么一年大概有18亿的数据，按照保留两年的热数据量大概是40亿，再做一些空间预留算50亿。那么可以按照32个库，每个库32个表来规划，一共1024张表，每张表500w的数据，便可以满足50亿的数据规划。在这个方案中我们可以选择orderID作为分片键，采用一致性哈希算法来路由。

在性能层面假设每个库正常写入的并发量是1000,那32个库可以承载32000的并发量。如果每个库的写性能再优化到1500，就意味着这个方案能支持接近5w每秒的写并发

需要考虑的其他问题

业务需要根据用户id查找，而用户id不是分片键导致查找复杂怎么解决？

• 我们可以采用基因算法确保用户id对应的订单id路由到同一个库或者同一个表，在生成订单ID的时候把用户ID的基因片段拼接到订单ID中，从而保证不管是通过订单ID还是用户ID都能路由到同一个表。

虽然设计了1024个表，但也只能存储50亿的数据，也就只能存储三年的数据，三年后方案就不满足了怎么解决?

• 订单这种业务我们频繁访问