本文是《Redis内部数据结构详解》系列的第二篇，讲述Redis中使用最多的一个基础数据结构：sds。
不管在哪门编程语言当中，字符串都几乎是使用最多的数据结构。sds正是在Redis中被广泛使用的字符串结构，它的全称是Simple Dynamic String。与其它语言环境中出现的字符串相比，它具有如下显著的特点：
如果你使用过Redis，一定会像我一样对它的内部实现产生兴趣。《Redis内部数据结构详解》是我准备写的一个系列，也是我个人对于之前研究Redis的一个阶段性总结，着重讲解Redis在内存中的数据结构实现（暂不涉及持久化的话题）。Redis本质上是一个数据结构服务器（data structures server），以高效的方式实现了多种现成的数据结构，研究它的数据结构和基于其上的算法，对于我们自己提升局部算法的编程水平有很重要的参考意义。
当我们在本文中提到Redis的“数据结构”，可能是在两个不同的层面来讨论它。
当你在压力日趋增大的现代社会中疲于奔命的时候，又或者当诸多意想不到的失意或失败已经成为过去，你又重新鼓足勇气面对新的生活踌躇满志的时候，下面这种想法是否曾经在你脑海中出现过，哪怕只有一瞬？那就是：现实世界只不过是某个至高无上的存在——我们也许可以称其为上帝——所导演的一出情节太过跌宕的戏剧，又或者是一部沉闷无聊的电视剧。不管它是什么，关键是并非所有情节都按你预想的发展。更糟糕的是，也许当我们走到人生的终点，在这场人生大戏中准备谢幕的那一天，我们才发现，自己只不过是这场拙劣戏剧的一个小小的龙套而已，从头至尾也没有得到导演（上帝）的多少眷顾。
如果不是恰好你家里也有一个五岁的小女孩的话，你就不会理解《冰雪奇缘》在这个年龄的小孩子心中的分量，也不会理解艾莎公主在幼儿园小朋友当中深受喜爱的程度。
在送女儿去幼儿园的路上，我们又一次聊起了艾莎。
“你喜欢艾莎还是安娜呢？”我问她。
“我喜欢艾莎。”女儿毫不犹豫地说。
“为什么呢？”
“因为艾莎会魔法。”
本文是系列文章《Android和iOS开发中的异步处理》的第三篇。在本篇文章中，我们主要讨论在执行多个异步任务的时候可能碰到的相关问题。
通常我们都需要执行多个异步任务，使它们相互协作来完成需求。本文结合典型的应用场景，讲解异步任务的三种协作关系：
本文是系列文章《Android和iOS开发中的异步处理》的第二篇。在本篇文章中，我们主要讨论跟异步任务的回调有关的诸多问题。
在iOS中，回调通常表现为delegate的形式；而在Android中，回调通常以listener的形式存在。但不管表现形式如何，回调都是接口设计不可分割的一部分。回调接口设计的好坏，直接影响整个接口设计的成功与否。
上周五和团队一起讨论了RxJava的用法和实现机制。在讨论中，@坚坚老师 问了一个有趣的问题：如果调用链中包含多个subscribeOn和observeOn，会是什么情况？
相信很多iOS App的开发者，特别是手游开发者，都接触过苹果支付IAP（In-App Purchase）。相信使用了IAP的App，都经历过“掉单”问题。
什么是“掉单”呢？简言之就是用户付款买金币，钱扣了，金币却没到账。
掉单一旦发生，用户通常会很愤怒地来找客服。然后客服只能找开发人员把金币给用户手动加上。