本周系统设计复习：
- 9 大最流行 API 协议
- 什么是死锁？
- 基于会话的认证和 JWT 有什么区别？
- 6 大 ElasticSearch 用例
- 100% CPU 使用率背后的 9 大原因
什么是死锁？
死锁发生在两个或更多事务相互等待对方释放它们继续处理所需资源的锁时。这导致一种情况，其中两个事务都无法继续，最终无限期等待。
Coffman 条件
Coffman 条件以 Edward G. Coffman, Jr. 命名，他在 1971 年首次概述了这些条件，描述了必须同时存在的四个必要条件才能发生死锁：
- 互斥（Mutual Exclusion）
- 持有并等待（Hold and Wait）
- 不可抢占（No Preemption）
- 循环等待（Circular Wait）
死锁预防
- 资源排序：对所有资源类型施加强制总排序，并要求每个进程以严格递增的顺序请求资源。
- 超时：持有资源太久的进程可以被回滚。
- 银行家算法：一种死锁避免算法，模拟资源分配给进程，并帮助基于资源的未来可用性决定是否安全授予资源请求，从而避免不安全状态。
死锁恢复
- 选择受害者：大多数现代数据库管理系统（DBMS）和操作系统实现复杂的算法来检测死锁并选择受害者，通常允许通过配置设置自定义受害者选择标准。选择可以基于资源利用率、事务优先级、回滚成本等。
- 回滚：数据库可以回滚整个事务或仅回滚足够打破死锁的部分。回滚的事务可以由数据库管理系统自动重启。
会话认证 vs. JWT
基于会话的认证
在这种方法中，你将会话信息存储在数据库或会话存储中，并将会话 ID 交给用户。
想象一下，就像乘客只拿到机票的 ID，而所有其他详情存储在航空公司的数据库中。
工作流程：
- 用户发出登录请求，前端应用将请求发送到后端服务器。
- 后端使用密钥创建会话并将数据存储在会话存储中。
- 服务器发回带有唯一会话 ID 的 cookie 给客户端。
- 用户发出新请求，浏览器发送会话 ID 与请求一起。
- 服务器使用会话 ID 认证用户。
基于 JWT 的认证
在 JWT 方法中，你不将会话信息存储在会话存储中。
所有信息都在令牌内可用。
想象一下，就像拿到机票，所有详情都在票上但已编码。
工作流程：
- 用户发出登录请求，它去到后端服务器。
- 服务器验证凭据并发布 JWT。JWT 使用私钥签名，不涉及会话存储。
- JWT 传递给客户端，要么作为 cookie 要么在响应体中。两种方法都有优缺点，但我们选择了 cookie 方法。
- 对于每个后续请求，浏览器发送带有 JWT 的 cookie。
- 服务器使用秘密私钥验证 JWT 并提取用户信息。
ElasticSearch 6 大用例
Elasticsearch 因其强大和多功能的搜索能力而广泛使用。下图显示了前 6 个用例：
全文搜索：Elasticsearch 在全文搜索场景中表现出色，因其强大、可扩展和快速的搜索能力。它允许用户执行复杂查询，具有近实时响应。
实时分析：Elasticsearch 实时执行分析的能力使其适用于跟踪实时数据的仪表板，如用户活动、交易或传感器输出。
机器学习：随着 X-Pack 中机器学习功能的添加，Elasticsearch 可以自动检测数据中的异常、模式和趋势。
地理数据应用：Elasticsearch 通过地理空间索引和搜索能力支持地理数据。这对于需要管理和可视化地理信息的应用很有用，如映射和基于位置的服务。
日志和事件数据分析：组织使用 Elasticsearch 聚合、监控和分析来自各种来源的日志和事件数据。它是 ELK 栈（Elasticsearch、Logstash、Kibana）的关键组件，用于管理系统和应用日志以识别问题和监控系统健康。
安全信息和事件管理（SIEM）：Elasticsearch 可用作 SIEM 工具，帮助组织实时分析安全事件。
100% CPU 使用率的 9 大原因
下图显示了可能导致 100% CPU 使用率的常见罪魁祸首。理解这些可以帮助诊断问题和提高系统效率。
- 无限循环
- 后台进程
- 高流量量
- 资源密集型应用
- 内存不足
- 并发进程
- 忙等待
- 正则表达式匹配
- 恶意软件和病毒
本文为学习目的的个人翻译，译文仅供参考。
原文链接：EP112: What is a deadlock?。
版权归原作者或原刊登方所有。本文为非官方译本；如有不妥，请联系删除。