本文主要介绍流媒体的概念、协议与编码技术，并对点播与直播场景的差异，以及Web端支持与限制展开分析，为满足实时互动与低延迟需求提供参考。
TIP：「流媒体方案」为重点章节。
什么是流媒体？
流媒体是一种通过互联网实时传输音频、视频或其他多媒体内容的技术。与传统的下载模式不同，流媒体允许用户在内容未完全下载的情况下，即时播放或观看内容。它的核心特点是数据会以连续的流形式传输到用户的设备上，而不是一次性下载整个文件。
常见的流媒体应用包括视频流媒体（如 Netflix、YouTube）、音频流媒体（如 Spotify、Apple Music）以及实时直播（如 Twitch、抖音直播）。流媒体技术的优势在于节省存储空间、减少等待时间，并能够支持实时互动和广播。
Elasticsearch Mapping 类似关系数据的的 schema（模式），Mapping 记录了索引的字段、字段数据类型，以及 Lucene 是怎样索引数据的。
在给新业务数据建索引时，需要进行的第一步就是 Mapping 设计，许多不重视的这个环节的，数据量增大后就暴露出了问题。
创建索引需要通常需要指定三部分内容：
{
"settings": {},
"mappings": {},
"aliases": {}
}
Elasticsearch 8.x 默认开启了安全功能，在远程服务器配置多实例时很容易安装失败，官方的教程只适合本地单实例启动，对于那些想探索 Elasticsearch 高级特性的人需要折腾一大阵，不知折戟沉沙了多少人。
本文主要介绍多实例 Elasticsearch 集群搭建，最后安装 Kibana 实现查询管理。
注意本教程的软件版本，后期的版本可能不适用。
发布订阅(pub/sub)是一种消息通信模式，本质是实现队列（先进先出）的远程操作功能。
使用 redis 实现发布订阅有 3 种方式：
结论：虽然 redis 可以作为消息队列，但是严谨的生产环境还是应该选择专业的 MQ，因为可靠性是软件的基石。
redis 有三种缓存淘汰策略，分别是 noeviction、volatile、allkeys。
无论前后端，大家在提到性能时总爱用 QPS，这样表达性能合理吗？
QPS 与 TPS，它们的区别是什么？
本文围绕这些问题展开。
协程本质上和线程是一类概念，本质上是编程过程中对并发计算任务的一种抽象，只不过协程在调度层面上更轻量。
线程的调度由于是操作系统实施的，有时间片/中断等较为复杂的机制，因此调度点对用户是透明的，可以认为调度理论上可以在任何地方触发。而协程的调度点往往是用户代码显式通过触发的（发生在用户态），需要用户代码自己相互“协作”来完成任务的调度和执行，这也是协程中”协“的来源。
Rebalance 是指，将一个 Topic 下的多个队列，在同一个消费组的多个成员之间进行重新分配。
比如，一个 Topic 下 8 个队列，只有一个消费者时，一个消费者将处理 8 个队列的消息。如果在组内增加一个消费者，在不重启服务的情况，将 8 个队列分配给两个消费者，从而支持动态的并行处理消息。
上周末和朋友一起去了乌兰察布，广袤的草原和火山，整个景色给人的感觉很空旷，让人很放松，工作久了出来转一转还不错。我们游玩的顺序是：乌兰哈达的 5 号火山 -> 2 号火山 -> Day2 -> 黄花谷，整个旅程中除了在路上花费了一些时间外，体验还是不错的。
在下面还有一些拍的视频。