网站模板怎么导入,双流规划建设管理局网站,在哪里可以做网站,自己怎样建立个人网站1.面试官#xff1a;Kafka 百万消息积压如何处理#xff1f; 2.面试官#xff1a;最多一次、至少一次和正好一次有什么区别? 3.面试官#xff1a;你项目是怎么存密码的? 4.面试官#xff1a;如何设计一个分布式ID#xff1f; 5.面试官#xff1a;单点登录是怎么工作的… 1.面试官Kafka 百万消息积压如何处理 2.面试官最多一次、至少一次和正好一次有什么区别? 3.面试官你项目是怎么存密码的? 4.面试官如何设计一个分布式ID 5.面试官单点登录是怎么工作的 6.面试官如何设计安全的对外 API 7.面试官如果你的项目要支持百万用户你会如何设计 8.面试官如果你的项目用户规模放大了 100 倍怎么应对 9.面试官你的项目如何做到高可用、高吞吐、高扩展性 10.面试官CPU 100% 问题怎么排查 1.面试官Kafka 百万消息积压如何处理
当 Kafka 出现百万级消息积压时可以从以下几个方面处理
定位问题
先检查消费组的 Lag消息积压量确认是消费者处理能力不足还是生产端消息量过大导致的。提升消费能力
增加消费者实例数 增加消费者实例来分摊压力但确保实例数不超过分区数。
优化消费逻辑 使用批量拉取和异步处理减少单条消息的处理时间。
跳过无关消息如果业务允许 临时将 offset 调整到最新位置优先处理新消息。优化 Kafka 配置
调整消费端参数比如增大 max.poll.records 和 fetch.max.bytes提高拉取效率。
如果 Broker 性能不足可以扩容集群或增加分区将负载分散。控制生产速度
对生产端限流避免消息积压进一步恶化。清理积压消息最后手段
如果消息已经过期或无用可以调整 offset 或删除积压消息。总结 处理积压关键在于快速提升消费能力并结合优化生产消费的配置确保系统及时恢复正常运行。
2.面试官最多一次、至少一次和正好一次有什么区别?
“最多一次”、“至少一次”和“正好一次”是分布式系统中常见的消息投递语义用来描述消息在网络中被传递的行为方式。 企业在设计分布式系统时通常根据业务需求选择 最多一次 低成本高吞吐对可靠性要求低的场景。投递一次甚至不投递 至少一次 适合高可靠性需求允许通过逻辑处理重复消息。至少投递一次甚至更多 正好一次 适用于对准确性要求极高的关键业务。投且投递一次
3.面试官你项目是怎么存密码的?
采用 bcrypt/Argon2 哈希密码存储结合随机盐值确保唯一性并使用 HTTPS 加密传输。
4.面试官如何设计一个分布式ID
设计分布式 ID 时需要权衡 场景需求 是否需要有序性、分布式部署、抗单点故障。性能要求 每秒生成量是否满足高并发需求。企业一般会根据具体场景选用合适的方案如雪花算法解决高性能问题号段模式减少数据库压力Redis 保证灵活性。
一、为什么分布式 ID 是一个重要问题
唯一性
在分布式系统中多个服务实例和数据库节点需要生成全局唯一的 ID避免数据冲突。
例如订单号、用户 ID 等不能重复。
高性能
分布式 ID 的生成需要满足高并发场景比如每秒生成百万级 ID。
有序性
一些场景需要生成的 ID 具有顺序性如时间递增方便排序和索引优化。
可扩展性
系统需要支持节点动态扩展或收缩ID 生成机制不能成为瓶颈。二、如何设计一个分布式 ID
常见的分布式 ID 设计方案如下
1. 数据库自增 ID
利用数据库的自增字段生成唯一 ID。
优点 简单易用ID 有序。
缺点 性能瓶颈高并发下会锁表数据库故障导致不可用。
2. UUIDUniversally Unique Identifier
直接调用系统提供的 UUID 生成方法。
优点 易实现生成快ID 唯一。
缺点 长度较长128 位不适合索引缺乏有序性。
3. 号段模式Segment Model
从数据库中预分配一批连续的 ID 号段如[1-1000]每个节点使用自己的号段。
优点 高效、减少数据库压力。
缺点 数据库依赖批量失效可能浪费号段。
4. 雪花算法Snowflake Algorithm
Twitter 提出的分布式 ID 生成方案将 ID 拆分成以下部分
时间戳41 位 毫秒级时间表示当前时间。
数据中心 ID5 位 机器 ID5 位 标识生成 ID 的节点。
序列号12 位 每毫秒内生成的序号防止重复。
优点 高性能、低延迟、时间有序、去中心化。
缺点 实现复杂需要全局时钟同步。
5. 基于 Redis 的分布式 ID
使用 Redis 的自增操作INCR生成 ID。
优点 高性能Redis 天生支持分布式。
缺点 Redis 故障会影响 ID 生成。
6. Zookeeper 分布式 ID
利用 Zookeeper 的顺序节点生成全局唯一的 ID。
优点 可靠性高ID 有序。
缺点 性能一般每次生成都需要写 Zookeeper。三、现在企业是如何解决分布式 ID 的问题
互联网公司高性能场景
雪花算法Snowflake 常用于订单号、用户 ID 等。
例如Twitter 原创国内很多公司如阿里、字节都有改进版本。
号段模式 数据库或缓存预分配号段适合稳定、高并发场景。
金融领域有序性要求高
使用 Zookeeper 顺序节点或基于数据库主键生成。
对事务一致性和顺序要求高的场景。
大规模分布式系统
利用 Redis 集群作为 ID 生成器结合雪花算法或分片机制。5.面试官单点登录是怎么工作的
单点登录SSO 通过一个统一的认证中心管理 用户登录状态不同系统之间通过共享 Token 或凭证实现登录信息的同步。它提升了用户体验同时简化了系统的认证流程。 6.面试官如何设计安全的对外 API
如果要设计一个安全的对外 API我会从以下几个方面入手
认证和授权
使用 OAuth 2.0 或 JWT 来认证用户身份确保调用者合法。
通过角色或权限控制RBAC/ABAC限制用户访问特定资源。数据加密
强制 HTTPS确保传输中的数据被加密。
对敏感数据进行字段级加密并对返回结果做数据脱敏。防护机制
使用时间戳和签名机制防止重放攻击。
针对敏感接口比如登录加验证码和失败次数限制防止暴力破解。
实施限流策略防止恶意刷 API比如单 IP 每秒限制请求次数。错误和暴露控制
返回的错误信息只提供必要信息避免暴露内部系统细节。
只开放必须的接口隐藏无关的内部实现。安全监控
记录和审计所有 API 请求日志实时监测异常流量便于追溯和故障排查。定期更新
定期轮换密钥、修补依赖库漏洞同时进行安全测试确保系统长期安全。通过以上方法可以有效保证对外 API 的数据安全和系统稳定性同时降低潜在风险。
7.面试官如果你的项目要支持百万用户你会如何设计
和第八题类似一起回答。 其实本质就是将单体项目逐渐改进到分体项目的过程。首先是把数据和应用分割到两个不同服务器然后分别优化应用和数据形成各自的集群引入主副主从各种微服务组件。 架构设计分层解耦支持高并发。我会采用分层架构和分布式设计分解系统的功能模块每层专注处理自己的职责。 前端层负载均衡 CDN
部署CDN内容分发网络将静态资源如图片、CSS、JavaScript缓存到边缘节点减少服务器压力提升用户访问速度。
使用负载均衡器如 Nginx、HAProxy将流量分发到多台后端服务器支持水平扩展。
应用层
应用服务会采用无状态设计状态信息存储在缓存或数据库中方便应用服务扩容。
服务拆分为独立的微服务按功能解耦如用户服务、订单服务、支付服务通过 API 网关如 Kong统一管理。
数据层
使用分布式数据库如 MySQL 分片、TiDB支持海量数据存储和查询。
利用读写分离主库写数据多个从库读数据提高读性能。
引入分布式缓存如 Redis、Memcached加速高频访问数据如用户会话、热点数据等。高并发异步 分布式队列 异步处理对于耗时操作如下单后发通知使用消息队列如 Kafka、RabbitMQ异步处理减少用户等待时间。异步任务处理还能平滑流量峰值。限流和降级在接口层实现限流策略如漏桶算法、令牌桶算法来保护系统防止流量暴增导致崩溃。非核心服务出现压力时可以降级如取消某些推荐功能。数据库设计分区分库分表 分区和分表按用户 ID 或订单 ID 对表进行分区或分表降低单表的数据量提升查询效率。分库数据按业务或地理位置拆分到不同的数据库节点形成分布式数据库集群。事务处理分布式事务可通过 **两阶段提交2PC或最终一致性TCC 模式) ** 来保证。高可用性多副本 故障恢复 服务高可用通过服务注册与发现如 Eureka、Consul让服务实例自动接管流量实现无缝扩容或切换。应用层部署多个实例利用健康检查机制快速剔除故障实例。数据库高可用数据库采用主从复制或多主架构主节点故障后快速切换到从节点。灾备设计跨数据中心部署关键数据进行定时备份保证在意外情况下的快速恢复。可扩展性按需扩容 通过容器化和编排工具如 Docker Kubernetes实现弹性扩容根据流量动态调整实例数量低谷时释放资源高峰时自动扩展。性能优化监控和调优 全链路监控部署监控工具如 Prometheus Grafana监测各模块性能实时报警异常情况。代码和查询优化数据库查询建立合理索引避免全表扫描。服务接口按热点和冷门数据优化响应逻辑提升吞吐量。8.面试官如果你的项目用户规模放大了 100 倍怎么应对
9.面试官你的项目如何做到高可用、高吞吐、高扩展性
高可用的意思就是保证服务尽可能保证处于正常状态例如4个999.99%的时间内都是正常的。这一思路就是主从集群之类的保证一台服务器宕机立马会有其他副本服务器顶上。
高吞吐服务需要在一段时间内处理大量请求。常用的指标是 QPS每秒查询次数或 TPS每秒事务次数。为了实现高吞吐量我们通常会在架构中添加缓存 以避免经过数据库或磁盘等较慢的 I/O 设备。我们还可以为计算密集型任务增加线程数量。 我们还可以在系统中使用异步处理以有效地单独隔离耗时耗资源的组件。
高扩展性意味着系统可以快速、轻松地扩展以容纳更多的容量**横向可扩展性** 或更多的功能纵向可扩展性。 要实现高度可扩展性需要隔离每个服务的职责。为此微服务被广泛采用 。我们还利用服务注册和负载平衡器 将请求路由到适当的实例。
10.面试官CPU 100% 问题怎么排查
基本思路就是先判断占用cpu资源最多的进程如果是服务程序大致可以使用两种方式。 系统工具 jstack 适合手动分析步骤清晰适合初步排查。 Arthas 提供更友好的交互界面和实时分析功能适合快速深入定位问题。
top进程然后找线程最后找到对应代码块获得占用的核心步骤。
