Java常见的设计

最新推荐文章于 2024-10-14 00:00:00 发布

文什

最新推荐文章于 2024-10-14 00:00:00 发布

阅读量663

点赞数 7

文章标签： java 开发语言

本文链接：https://blog.csdn.net/winstonYep/article/details/141019759

版权

幂等性是什么，如何在设计接口或方法时保证幂等性

执行多次相同操作，结果都一样（只执行1次）

使用唯一标识符：每个请求唯一，服务端检查是否已处理
接口本身实现：
- 比如插入一条数据，若已存在，则不插入。
- 乐观锁或版本控制，避免重复更新数据。
记录操作日志：若日志已存在，返回之前的结果。

转账场景的幂等性

请求唯一标识、状态机、分布式锁、数据库唯一约束（账户+金额）、请求日志

“==” 和 “equals” 的区别和使用场景

==和equals都可以用于比较两个对象是否相等，但它们的比较方式和使用场景有所不同。

==
- 比较两个对象的引用是否相等，即是否指向同一个对象（是比较运算符）
- 比较基本数据类型的值是否相等
equals：
- 用于比较两个对象的内容是否相等（Object类中的一个方法）
  - 默认情况下，equals方法比较的是两个对象的引用是否相等（可重写）
  - 但很多类都重写了equals方法，以实现自己的比较逻辑
    - 例如，String类重写了equals方法，比较的是两个字符串的内容是否相等。
- 比较两个字符串的内容是否相等

hashCode和equals

如果类没有重写equals方法，那么默认情况下，equals方法比较的是两个对象的引用是否相等，而不是类的hashCode。

hashCode方法返回一个对象的哈希码值，用于在哈希表等数据结构中快速查找和定位对象。默认返回的是对象的内存地址。

如果两个对象的hashCode值相等，那么它们的equals方法比较结果也应该相等。但是，hashCode值相等并不一定意味着equals方法比较结果相等，因为hashCode值可能会发生冲突。

因此，在使用hashCode方法和equals方法时，需要确保它们的实现符合预期，并且在需要比较对象是否相等时，应该使用equals方法而不是hashCode方法。

Object对象的equals和hashCode方法

public boolean equals(Object obj) { return (this == obj); } @IntrinsicCandidate public native int hashCode();

高并发系统设计

可以分为以下 6 点：

系统拆分：将一个系统拆分为多个子系统，用 dubbo 来搞。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么
缓存：大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。毕竟人家 redis 轻轻松松单机几万的并发
MQ：大量的写请求灌入 MQ 里，排队慢慢玩儿，后边系统消费后慢慢写，控制在 mysql 承载范围之内。所以你得考虑考虑你的项目里，那些承载复杂写业务逻辑的场景里，如何用 MQ 来异步写，提升并发性。MQ 单机抗几万并发也是 ok 的
分库分表：将一个数据库拆分为多个库，多个库来扛更高的并发；然后将一个表拆分为多个表，每个表的数据量保持少一点，提高 sql 跑的性能
读写分离：主从架构，主库写入，从库读取，搞一个读写分离。读流量太多的时候，还可以加更多的从库
ElasticSearch：es 是分布式的，可以随便扩容，分布式天然就可以支撑高并发，因为动不动就可以扩容加机器来扛更高的并发。那么一些比较简单的查询、统计类的操作，可以考虑用 es 来承载，还有一些全文搜索类的操作，也可以考虑用 es 来承载

秒杀业务的特点、挑战以及常见的解决方案吗

秒杀业务是一种高并发、限时抢购的业务场景，具有以下特点：

瞬间高并发：在秒杀活动开始时，会有大量用户同时发起请求，导致系统瞬间承受巨大的流量压力。
库存有限：秒杀商品的数量通常是有限的，需要确保库存的准确性和一致性。
时间限制：秒杀活动通常有严格的时间限制，需要在规定的时间内完成抢购。
数据一致性：在高并发情况下，需要保证订单、库存等数据的一致性，避免出现超卖等问题。

秒杀业务面临的挑战主要包括：

高并发请求处理：如何应对瞬间大量的请求，确保系统的稳定性和性能。
库存管理：如何准确地管理库存，避免超卖或库存不足的情况。
数据一致性：在高并发环境下，如何保证订单、库存等数据的一致性。
恶意攻击防范：如何防范恶意攻击，如刷单、黄牛党等。
用户体验：如何在高并发情况下，保证用户能够快速、流畅地完成抢购流程，提高用户体验。

针对秒杀业务的挑战，可以采用以下常见的解决方案：

流量削峰：通过使用消息队列、异步处理等技术，将瞬间的高并发请求进行削峰处理，缓解系统的压力。
库存预热：提前将秒杀商品的库存加载到缓存中，减少数据库的访问压力，提高库存查询的效率。
分布式锁：使用分布式锁来保证库存的准确性和一致性，避免超卖等问题。
数据缓存：将频繁访问的数据缓存到内存中，提高数据的访问速度，减少数据库的压力。
限流：通过限制每秒的请求数量，防止系统被瞬间的高并发请求压垮。
异步处理：将一些耗时的操作异步化，如订单处理、库存扣减等，提高系统的响应速度。
安全防范：采用验证码、IP 限制、用户行为分析等技术，防范恶意攻击和刷单行为。
监控和预警：建立完善的监控系统，实时监控系统的性能指标和业务数据，及时发现和处理问题。

性能要求

QPS：系统需要能够处理每秒数万甚至数十万的请求量，以确保用户能够快速完成秒杀操作。
响应时间：响应时间应该在几十毫秒以内，以提供流畅的用户体验。
成功率：成功完成秒杀操作的用户比例应该尽可能高，例如 99%以上。
库存准确性：系统需要确保库存的准确性，避免出现超卖或库存不足的情况。
可扩展性：系统需要能够根据业务的增长进行扩展，以满足不断增长的并发请求量。
稳定性：系统需要在高并发情况下保持稳定，避免出现崩溃或性能下降的情况。

接口限流，策略及实现方式

令牌桶算法（Token Bucket Algorithm）：令牌桶算法是一种基于令牌的限流算法。在令牌桶中，以固定的速率产生令牌，每个请求需要获取一个令牌才能被处理。如果令牌桶中没有足够的令牌，则请求会被暂时阻塞或拒绝。令牌桶算法可以通过使用计时器和队列来实现。
漏桶算法（Leaky Bucket Algorithm）：漏桶算法是一种基于漏桶的限流算法。在漏桶中，以固定的速率处理请求，如果请求到达时漏桶已满，则请求会被暂时阻塞或拒绝。漏桶算法可以通过使用计时器和队列来实现。
计数器算法（Counter Algorithm）：计数器算法是一种简单的限流算法，通过统计单位时间内的请求数量来进行限流。可以设置一个阈值，当请求数超过阈值时，请求会被暂时阻塞或拒绝。计数器算法可以使用原子计数器或分布式计数器来实现。
基于时间窗口的限流：基于时间窗口的限流是一种简单有效的限流策略。可以设置一个时间窗口，统计该时间窗口内的请求数量，如果请求数超过阈值，则请求会被暂时阻塞或拒绝。可以使用定时器和计数器来实现基于时间窗口的限流。
第三方限流组件：除了自己实现限流算法外，还可以使用一些第三方限流组件来简化开发。例如，Redis提供了基于令牌桶和漏桶算法的限流功能，可以使用Redis的计数器和定时器来实现限流。

后端安全有哪些要注意

身份验证和授权：确保只有经过授权的用户能够访问后端资源。使用强大的身份验证机制，如用户名/密码、令牌或多因素身份验证。实施适当的授权策略，以限制用户对特定功能和数据的访问权限。
输入验证：对用户输入进行严格的验证和过滤，以防止常见的安全漏洞，如 SQL 注入、跨站脚本攻击（XSS）和跨站请求伪造（CSRF）。验证输入的类型、长度、格式和范围，并拒绝不符合预期的输入。
密码管理：使用安全的密码存储方法，如哈希加盐。避免在数据库中存储明文密码。强制用户使用强密码，并定期要求用户更改密码。
安全配置：确保后端服务器和应用程序的配置安全。关闭不必要的服务和端口，限制对敏感文件和目录的访问权限。及时更新服务器和应用程序的补丁，以修复已知的安全漏洞。
数据加密：对敏感数据进行加密，无论是在传输过程中还是在存储中。使用安全的加密算法和协议，如 SSL/TLS 用于网络通信，以及加密存储用于数据库中的敏感信息。
访问控制：实施访问控制列表（ACL）或基于角色的访问控制（RBAC），以确保只有授权的用户能够访问特定的资源和操作。限制管理员权限的分配，并定期审查和调整访问权限。
防止 SQL 注入：使用参数化查询或存储过程来防止 SQL 注入攻击。避免直接拼接用户输入到 SQL 查询中。
防止 XSS 和 CSRF：对用户输入进行输出编码，以防止 XSS 攻击。实施 CSRF 令牌验证，以防止跨站请求伪造。
安全审计和监控：启用日志记录和监控功能，以便及时检测和响应安全事件。定期审查日志，查找异常活动和潜在的安全威胁。
安全开发实践：遵循安全编码标准和最佳实践，进行安全的开发和测试。进行代码审查，以发现和修复潜在的安全漏洞。
第三方库和组件管理：定期审查和更新使用的第三方库和组件，以确保它们没有已知的安全漏洞。
数据备份和恢复：定期备份数据，并确保备份的安全性和可恢复性。制定灾难恢复计划，以应对数据丢失或系统故障的情况。
安全意识培训：对开发团队和用户进行安全意识培训，提高他们对安全威胁的认识，并教导他们如何采取安全措施。