【App后台Keynote】
一、基础。
1、一个 节省 流量 的 处理 方法 是 让 App 下载 经过 压缩 的 图片（ 一般 是 几十 KB 以下）， 当 用户 需要 查看 原图 时 才 下载 原图。
2、Openfire（ Openfire 是一 个 开源 的 聊天 服务器）。
3、在 www. sosoapi. com 中 可以 管理 创建 的 所有 接口。
4、当 App 客户 端 需要 某种 尺寸 的 图片， 由 App 客户 端 通知 服务 端 所需 图片 的 尺寸， 由 服务 端 动态 生成 并 缓存。
5、返回 信息 最 科学 的 情况 是 App 后台 只 返回 信息 代码， 具体 的 文字 提示 由 App 客户 端 决定。
6、为了 避免 同一个 App 客户 端 中 调用 不同 版本 的 API， 一般 会 全部 升级 API 的 版本。
7、MongoDB
1）MongoDB 同时 使用 了 硬盘 和 内存， 其 使用 了 操作系统 提供 的 MMAP（ 内存 文件 映射） 机制 进行 数据 文件 的 读写， MMAP 可以 把 文件 直接 映射 到 进程 的 内存 空间 中。
2）MongoDB 可以 查找 在某 个 矩形 范围内 的 所有 坐标， 因此 MongoDB 非常 适合于 LBS 应用。
3）MongoDB 不适用于事务型、复杂SQL查询的场景。
8、MySQL
1）MySQL 的 数据 是 放在 硬盘 中。 虽然 MySQL 也有 缓存， 但 MySQL 缓存 的 是 查询 的 结果， 而 不是 缓存 数据。
2）事务性，复杂SQL。
9、有大 量 开源 的 应用 可作 为 消息 队列 的 服务 端， 例如 RabbitMQ ，ZeroMQ ，Redis 等。
10、IETF 就在 1999 年 把 SSL 协议 标准化。 SSL 协议 标准化 之后 的 名称 改为 TLS（ Transport Layer Security） 协议， 中文 称为“ 传输 层 安全 协议”。
二、
1、FFmpeg 的 官 网（ http:// ffmpeg. org/） 是 这样 介绍 的： A c omplete, c ross- platform s olution t o record, convert and stream audio and video。
2、FastDFS 是一 个 开源 的 轻量级 分布式 文件 系统。
3、推荐 使用 GraphicsMagick 作为 图片 处理 软件， 其是 一个 久经考验 的 软件， 支持 多个 平台， 支持 多种 语言 客户 端， 处理 速度快， 消耗 资源 少， 并且 规模 较大 的 图片 网 站 如 Flickr 都在 使用 GraphicsMagick。
4、CDN 最大 的 作用 是 使 图片、 音频、 视频 等 静态 文件 下载 速度 更快， 用户 体验 更好。App 后台 访问 量大 时 通过 CDN， 可以 把 图片、 音频、 视频 等 静态 文件 请求 提前 响应， 不让 其 到达 应用 服务器， 也是 一种 应付 高 并发 的 方法。
5、ELK （Logstash+ ElasticSearch+ Kibana） 这个 分布式 的 日志 收集 和 分析 系统。
三、
1、查询 系统 文件 描述 符 大小 的 命令 如下。
[root@ modecron]# ulimit -n 1024
2、top 命令 提供 实时 的 系统 处理器 的 状态 监视。
3、僵尸 进程 指的 是 那些 已经 终止， 但 仍然 保留 一些 信息 的 进程， 等待 父 进程 为 其 调用 wait() 系统 调用 来 获取 子 进程 的 退出 状态 和 其他 的 信息（ 即为 其 扫尾）。 当 调用 父 进程 为 其 调用 wait() 后， 僵尸 进程 就 完全 从 内存 中 移 除。
僵尸 进程 无法 使用 kill 清理。 如果 开发者 需要 手动 清理 僵尸 进程， 要找 到 其父 进程， 把 父 进程 kill 掉 后 Linux 的 init 将 接管 其 子 进程。
4、lsof（ list open files） 是一 个 列出 当前 系统 打开 文件 的 工具。
5、supervisor 是 用 Python 语言 编写 的 基于 Linux 操作系统 的 一 款 进程 管理 工具， 用于 监控 进程 的 运行， 当 发现 进程 闪 退 时能 自动 重 启。
6、Nginx 的 高性能 主 要是 其 使用 了 epoll、kqueue。 Apache 所 采用 的 select 网络 I/ O 模型 是非 常 低效 的。
四、MySql
1、MySQL 在 架构 上 分为 三层。
1）服务层/连接层。
2）核心层。
3）存储引擎层。
2、MySQL 被 Oracle 收购 后， MySQL 创始人 Monty W idenius 主导 开发 了 MariaDB， 采用 GPL 授权 许可， 完全 兼容 MySQL， 使用 XtraDB 存储 引擎 来 代替 MySQL 的 InnoDB 存储 引擎。
3、MyISAM 基于 ISAM（ 索引 顺序 访问 方法) ，支持 全文 索引， 但 并非 是 事务 安全， 不支持 外 键， 使用 表 级 锁。
每个 MyISAM 表 存有 3 个 文件：
1）FRM 文件 存放 表 结构。
2）MYD 文件 存放 数据。
3）MYI 存放 索引。
4、InnoDB 是 事务 型 存储 引擎， 其 支持 行 锁。
5、读写分离/主从架构。
MySQL 主从 复制 是 异步 复制， 在 主 数据 与 从 数据库 之间 实现 整个 主从 复制 的 过程 有 三个 线程 参与， 其中 两个 线程（ SQL 线程 和 IO 线程） 在 从 数据库， 另外 一个 线程（ IO 线程） 在 主 数据。
五、Redis
1、提供 了 AOF 和 RDB 两种 数据 的 持久 化 方式， 保证 了 Redis 重 启 后 数据 不 丢失。
2、Redis 的 所有 操作 都是 原子 性， 同时 Redis 还 支持 对 几个 操作 合并 后的 原子 性 操作， 也即 支持 事务。
3、list 在 Redis 中 是 链 表 结构。
4、可以设置超时时间，超过 超时 时间 后， 该 Key 与 对应 的 数据 会被 Redis 删除。 通过 删除 过期 的 Key， 可以 在 一定程度 上 优化 内存 的 使用。
5、Twemproxy 是由 Twitter 开源 的 Redis 代理， 其 基本 原理 是： Redis 客户 端 把 请求 发送 到 Twemproxy， Twemproxy 根据 路 由 规则 发送 到 正确 的 Redis 实例， 最后 Twemproxy 把 结果 汇集 返回 给 客户 端。
Twemproxy 通过 引入 了 一个 代理 层， 将 多个 Redis 实例 进行 统一 管理， 使 Redis 客户 端 只需 要在 Twemproxy 上进 行 操作， 而 不需要 关心 后面 有 多少 个 Redis 实例， 从而 实现 了 Redis 的 集群。
6、Twemproxy 不能 平滑 增加 Redis 实例 的 问题 带来 了 很大 的 不便， 于是 豌豆荚 自主 研发 了 Codis， 一个 支持 平滑 增加 Redis 实例 的 Redis 代理 软件， 其 基于 Go 和 C 语言 开发， 并于 2014 年 11 月 在 Github 上 开源。
7、持久化：
1）RDB 是 Redis 默认 的 持久 化 方式， 这种 方式 是按 照 一定 的 时间 周期 策略 把 内存 的 数据 以 快照 的 形式 写入 到 硬盘 的 二进制 文件。 RDB 默认 的 数据 文件 是 dump. rdb，
2）使用 AOF 的 持久 化 方式， Redis 会把 每个 写入 命令 通过 write 函数 追加 到 持久 化 文件 中（ 默认 文件 是 Appendonly. aof）， 当 Redis 重 启 的 时候 会 通过 执行 持久 化 文件 的 写 命令 重建 内存 数据。
为了 压缩 AOF 文件， Redis 提供 了 bgrewriteaof 命令， Redis 收到 这个 命令 后 会 以 类似 创建 RDB 文件 的 方式 将 内存 数据 以 命令 的 形式 保存 到 临时 文件 中， 最后 替换 原 文件。
六、MongoDB
MongoDB 有两 个 基本 的 组件。
1）mongod： MongoDB 服务 端 程序， 启动 MongoDB 的 服务。
2）mongo： MongoDB 客户 端 程序， 连接 mongod 服务 端 进行 相关 的 管理 工作。
1、是非 关系 型 数据库 当中 功能 最 丰富、 最 像 关系 型 数据库 的 数据库。
2、全球 流行 的 LBS 应用 foursquare， 国内 的 快的 打车 和 滴滴 打车（ 现在 这 两家 公司 已 合并） 都曾 经 选择 了 MongoDB 处理 LBS。
3、副本 集 使用 多台 机器 做 同一 份 数据 的 异步 同步， 从而 使 多台 服务器 拥有 同一 份 数据 的 多个 副本。 一台 服务器 作为 主 节点 提供 写入 服务， 多台 服务器 作为 副本 节点 提供 读取 服务， 实现 读写 分离。
当 主 节点 宕 机 后， 可以 在 不需要 用户 干预 的 情况下 把 一台 副本 节点 或 其他 节点 提升 为主 节点， 继续 提供 服务。
4、MongoDB 分片 的 架构。
1）mongos： 作为 数据库 集群 请求 的 入口， 由于 数据 已经 分布 在 shard 服务器 上， 所有 请求 经过 mongos 转发 到 shard 服务器 上， mongos 充当 路 由 的 角色。
2）config server： 配置 服务器， 存储 了 所有 数据库 元 信息（ 路 由、 分片） 的 配置。
七、聊天后台架构
1）心跳。
2）图片、音频等大文件的处理。
3）聊天后台架构。
八、社交后台架构。
1、带虚拟结点的一致性hash算法。
2、主、 从 缓存 结构 中 从 缓存 是 作为 主 缓存 的 备份 存储。 大部分 的 请求 都 落在 主 缓存， 只有 少 部分 的 请求 会 落在 从 缓存， 这 造成了 主从 缓存 数据 的 剔除、 过期 策略 不一致。 如果 主 缓存 出了 问题， 请求 落在 从 缓存， 但在 从 缓存 上 只有 少 部分 数据 可供 访问， 请求 还是 会 穿透 到 数据库， 因此 从 缓存 作为 防止 单 点 失效 的 措施 是 无效 的。
一种解决方案。应用 层 控制 请求 有 一定 的 概率 落在 从 缓存， 让 从 缓存 承担 部分 请求， 使 从 缓存 中的 数据 不 过冷。
九、LBS后台架构。
1、geohash
1）geohash 编码， 就是 通过 算法 把 地理 坐标 转换 成 一个 值， 简单 点 来说 就是 把 二维 坐标 转换 成 一个 字符串。如坐标 是“ 113. 39175， 23. 061784”， 这个 坐标 同时 也可 以用 geohash 值“ ws0ehq32ek0u” 表示。
2）坐标 的 geohash 值 越 相似， 意味着 距离 越 相近。
3）geohash 值 越长， 表示 的 范围 越 精确。
2、MongoDB3. 0 的 WiredTiger 存储 引擎， 该 款 存储 引擎 支持 了 文档级别的锁。
3、MongoDB 的 一大 亮点 是 封装 了 大量 的 地理 位置 操作， 全球 流行 的 LBS 服务“ Foursquare”、 国内 著名 的 打车 App“ 快的” 也曾 经 使用 MongoDB 的 地理 位置 查询 功能。
十、推送后台架构。
1、由于 iOS 系统 的 限制， 应用 是 不允许 在后 台 运行 并 连接 网络 的。 如果 App 在 iOS 上 没有 运行， 但是 开发者 却 想 推送 消息 给 使用 该 App 的 iOS 用户， 只能 通过 APNS 推送 消息。
2、Android 手机 由于 Android 系统 没有 限制， 当 App 进入 了 后台 也能 运行 服务， 所以 Android 可以 基于 长 连接 作 推送。
十一、
1、高性能。
2、高可用。
高 可用 就是 要 保证 为 App 提供 7 × 24 小时 服务 的 App 后台， 服务器 不能 随便 宕 机， 或者 在 一个 服务器 集群 中， 部分 服务器 宕 机 了 也可以 保证 整个 服务 不 受到影响。
保证 负载 均衡 策略 有效 的 核心 是 应用 层 必须 是 无 状态 的。 所谓 无 状态， 是指 任意 一台 应用 服务器 上 不会 保存 用户 的 状态 信息（ 例如， 在 某台 服务器 上 保存 用户 已经 登录 的 凭证）。 用户 的 状态 信息 可以 存储 在 缓存 或 数据库， 供 所有 的 应用 服务器 共同 调用。
3、可伸缩。
可伸缩 是指 通过 往 集群 中 添加 机器， 应付 不断 增大 的 访问 压力 和数 据 存储 需求。
4、可扩展。
可扩展 性的 核心 是 减少 模块 间的 耦合 度， 每个 模块 都 尽量 少 依赖 其他 模块， 这样 其中 一个 模块 的 变化 对其 他 模块 的 影响 减少。
5、安全性。
参考：
1、《App后台开发运维和架构实践》
