Redis的常见业务场景。

消息队列是重要的分布式系统组件，在高性能、高可用、低耦合等系统架构中扮演着重要作用。可用于异步通信、削峰填谷、解耦系统、数据缓存等多种业务场景。本文是关于消息队列（MQ）选型和常见问题的精心整理。在这篇文章中，我们将详细介绍消息队列的概念、作用以及如何选择适合自己需求的消息队列系统。

过去几年的开发生涯，我一直都在思考 技术成长/核心竞争力 这些命题。

程序员这个行业面临的年龄危机和焦虑感是前所未见的，这些命题也将伴随程序员的整个职业生涯。在计算机软件工程的一些经历著作里面，前辈们也给出了不少关于这些方面的参考。但正如你无法只通过阅读理论而学会游泳一样，正如好的架构设计是慢慢地从解决问题和大量实践中生长出来的一样，真正的答案需要在大量的项目经验和编码实践中不断寻找。

我想，我的答案可能都藏在过程里面。作为一名非典型的前端开发，无论是在初期转做服务端开发工程师，还是负责开发亿级流量的前端监控接入层服务，又或是前端开发经历，虽说走了不少弯路，但都锻炼了我的技术能力，拓宽了我的技术视野，并且带给我很多解决问题的思维。

对于技术需要怎么具体地去学？项目需要怎么具体地去做？这些竞争力是不是能伴随我们度过 35 岁的门槛？希望我能通过这篇文章的复盘给出一些答案，同时能给各位读者一些启发。让我们一起共同面对这高悬头上的达摩克利斯之剑。

调度模块在很多系统中都是常用的模块，比如实习生的每天签到邮件，预约银行的业务短信，学习通的上课通知，腾讯视频push中台的任务下发，调度系统在中间起到关键作用。

软件设计模式是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。它的意义在于这些模式是众多程序员经过相当长的一段时间的试验和错误复盘所总结的宝贵经验，可以帮助我们提高代码的可重用性、可读性和可靠性。

Kotlin Native 是 Kotlin 多平台生态的关键一环，也是 Kotlin 开发者突破自身发展瓶颈的重要方向。本文依据 Kotlin Native 的源码，结合作者在运用 Kotlin Native 开发多平台应用的实战经验，详细为大家解读 Kotlin Native 在编译时和运行时的实现细节和实践技巧。

重型 JS 项目的性能问题一向很难，我们文档技术团队在 review 各大开源 JS 仓库性能实践的时候注意到：TS 源码的 checker.ts 这个文件相当暴力，它将 TS 完整类型系统全部逻辑 5.2 万行全部写在一个 TS 文件里，而文件大小则达到了惊人的 2.92 MB —— 这相当有趣，为什么？本文将带你从源码出发，分析背后的现象本质。

对于众多开发者而言，架构图不仅是一项不可或缺的技能，更是他们理解、规划和构建软件系统的关键工具。然而，面对多样化的系统需求和复杂的业务逻辑，如何画好一张架构图，成为了许多程序员面临的共同挑战。

2022手Q春节活动主会场页面日PV过亿，活动期间覆盖用户总数更是达到数亿，多项数据刷新历史纪录，本文从前端角度全面介绍了该项目的落地过程。

近年来，随着游戏行业的发展和国产游戏的崛起，越来越多的作品选择了 Unreal 引擎，《黑神话：悟空》这一旷世大作便是基于 Unreal 开发，更多我们熟知的游戏如《原神》、《王者荣耀》则是基于 Unity 开发。

鲁迅曾经说过：一个成功游戏引擎的背后，离不开一个默默支持他的热更脚本，不论你使用 Unreal 还是 Unity，不论你写 C++ 还是 C#，开发一款大型游戏，总是离不开热更新技术的支持，也离不开背后默默支持你热更的 Lua。

在这个不断变化的复杂世界里，人类每天会在搜索系统中敲下数万乃至上亿个问题，找寻答案，给自己的好奇一个归宿。而搜索系统就像一个输送管道，每日孜孜不倦地进行各种计算，浪里淘金，旨在为各种问题送上致命一击。在庞大的数据流中，答案的搜索往往离不开大量计算资源和时间；并且，随着问题越来越多，搜索系统的计算往往会出现挤兑，大大影响效率。因此，为搜索系统搭建一个有效的缓存机制，将会大幅提升计算效率，节省大量资源。

当你在浏览器输入 qq.com 按下回车键，到页面呈现在你面前，整个过程发生了什么？我以前思考过这个问题，从最前面的浏览器到最后的 db 都梳理的一遍，触发了一次技术顿悟，将很多散落的知识点贯通起来了。

在做程序设计的时候，开发同学往往都有类似的困惑：分不清楚业务用例图、系统用例图都是什么，二者的区别是什么，也不确定自己画的图对不对，会不会被评审挑战。

本文作者从业务建模角度切入，详细拆解了业务用例图和系统用例图的分析与画法，相信能够帮助你在之后的设计中画图信手拈来、得心应手。

用户行为是指用户与产品、服务、系统进行交互的方式。在当今社会，人们每天都会花费大量时间在互联网产品上。这些应用产品通过提供多样化的数字服务，使得人们的互动行为从原来的物理交互转变为虚拟交互。可以看出，行为本身具有一定的可塑性，可以通过各种内部或外部因素进行干预。那么作为设计师，我们该如何引导用户采取我们所期望的行为呢？「福格行为模型」可能会对我们有所启发。

程序员往往习惯于接到需求立马开始撸代码，原因无非是需求急任务重老板盯得紧。但在实际的开发场景中，我们往往会发现，写完代码，需求变了；人力多了，质量差了；业务代码，写起来没劲……

在追崇多人协作的现代软件开发体系下，这些问题背后的前置解决方案，其实就是设计和建模。本文将带你深入软件开发的初始，了解写代码前要做的几件事。

「迷思」是指经由人们口口相传，但又难以证明证伪的现象。由于 GPU 硬件实现、驱动实现是一个黑盒，我们只能通过厂商提供的 API、经过抽象的架构来了解并猜测其原理。因此坊间流传着各种关于与 GPU 打交道时的性能迷思。比如「移动端的瓶颈是带宽」、「移动端不需要太在意 Overdraw」、「植被需要做 PrePass」等等。这些优化手段，有时候我们对后面的原理一知半解，有时候又会随着硬件的发展而逐渐变得不适用，逐渐会变成一种神秘主义。