"惊群"简单地来讲，就是多个进程(线程)阻塞睡眠在某个系统调用上，在等待某个 fd(socket)的事件的到来。当这个 fd(socket)的事件发生的时候，这些睡眠的进程(线程)就会被同时唤醒，多个进程(线程)从阻塞的系统调用上返回，这就是"惊群"现象。"惊群"被人诟病的是效率低下，大量的 CPU 时间浪费在被唤醒发现无事可做，然后又继续睡眠的反复切换上。本文谈谈 linux socket 中的一些"惊群"现象、原因以及解决方案。

产品经理社群或平台上探讨需求上不了台面？你真的弄懂需求了吗？

随着品牌在微信生态建设私域流量的成熟，越来越多品牌要求门店导购肩负起顾客运营、线上小程序销售等任务，希望通过导购掌握的客户资产为品牌开拓新线上销售渠道。

REmote DIctionary Server(Redis) 是一个开源的使用 ANSI C 语言编写、遵守 BSD 协议、支持网络、可基于内存、分布式、可选持久性的键值对(Key-Value)存储数据库，并提供多种语言的 API。

Redis 通常被称为数据结构服务器，因为值（value）可以是字符串(String)、哈希(Hash)、列表(list)、集合(sets)和有序集合(sorted sets)等类型。

从 Vue 迁移到 React ，不太习惯 React Hooks 的使用？也许换个角度思考 Hooks 出现的意义会对你有所帮助。

leader 在安排事情的时候是怎么安排的？为什么这件事给 A 做会觉得比较放心，给B做心里会没底？尝试从大佬们的角度去分析问题，会发现大佬们的一些做事的方法论。 同一件事情，不同的人做，结果不一样，取决于有的人“会做事”、有的人“不会做事”；给 A 做比较放心，因为 A 一直都“会做事” 。

面试的时候问页面性能有哪些指标，却经常得到合并文件、压缩资源等优化手段的答案，是时候整体盘一下“性能指标”了。

本文的浏览器端 Sandbox 沙盒运行环境，大家可以快速理解为类似 CodeSandbox 一样，所有页面代码编译都在前端完成（不依赖后端），并且具备实时热更新功能。

而本文终极目标就是实现这样的浏览器端 Sandbox 沙盒运行环境，可以轻松接入到大部分平台（尤其低代码平台），提升应用的预览速度和开发体验。

近期，微信小游戏支持了视频号一键开播，其实现的过程可谓一波三折。微信小游戏运行在独立的进程中， 而视频号直播推流模块则必须运行在微信主进程，该采用什么方案进行画面和音频采集推流？——最终我们实现了一套跨进程渲染采集的方案。

随着网站升级 HTTP/2 协议，在浏览页面时常常会发现页面的请求数量很大，尤其是小图片请求，经典的雅虎前端性能优化军规中的第 1 条就是减少请求数，在 HTTP/1.1 时代合并雪碧图是这种场景减少请求数的一大途径，但是现在这些图片是使用 HTTP/2 协议传输的，这种方式是否也适用？另外，在都使用 HTTP/2 的情况，在浏览器并发这么多小图片请求时，是否会影响其他静态资源的拉取速度（例如页面 js 文件的请求耗时)？

存量业务在使用第三方框架的时候，是不是一定得按框架的规则进行大规模重构呢？本分享为大家介绍，兔小巢业务是如何在最小改动的情况下，利用 Taro 能力实现小程序多端同构。

近期使用了 cocos creator 来开发一些游戏化的课中互动。Cocos 是一个优秀的国产游戏引擎，可以通过 Javascript 写出跨平台的游戏。看完文档，吭哧吭哧搞完，看似完美运行，然而体验会上，大家却提出加载时黑屏时间长、手机发烫严重、闪退、卡顿等问题。头疼，只能想办法优化。

经过几天的优化，性能才渐渐达标，其间踩了不少坑，所以打算将一些性能问题排查和优化的手段记录起来，分享给有需要的同学。

你真的了解Android的线程优先级吗？ 看似无害的三行代码却隐藏着巨大的陷阱！ 真相只有一个！

本文在多个代码示例的辅助下讲解了 HTML5 中 canvas 对小数像素坐标的处理机制，介绍了一些 canvas 使用过程中经典问题的解决方案。

Raft的核心就是leader发出日志同步请求，follower接收并同步日志，最终保证整个集群的日志一致性。

在数据库或者存储的世界里，存储引擎的角色一直处于核心位置。往简单了说，存储引擎主要负责数据如何读写。往复杂了说，怎么快速、高效的完成数据的读写，一直是存储引擎要解决的关键问题。在绝大部分介绍、讲解存储引擎的书籍或者文章里，大家都默认了读多写少的磁盘存储引擎采用的就是 b+树，而极少有人来剖析选择 b+树作为索引结构的背后，到底有着怎样的思考和权衡？为了解答上述问题，本文尝试从一个新的视角和大家讨论：

在处理读多写少的场景下，为什么基于磁盘的存储引擎会选择用 b+树来作为索引结构？