Caching REST API Response 缓存是服务端在请求-响应路径中用来存储一份经常访问的数据的副本的功能。当一个用户请求一个资源的表现层时，请求通过缓存或多级缓存（本地缓存、代理缓存、反向代理）走向托管资源的服务。如果任何一级缓存拥有请求路径的资源表现层的新鲜副本的话，那么这份副本将会用来响应这个请求。如果所有缓存都不能满足这个请求，这个请求将一路传送至服务层（源服务器）。 在HTTP请求头中，源服务器说明一个响应是不是可缓存的，如果是的话，由谁来缓存，缓存的有效期是多少。在响应路径中，缓存可以将响应信息做一个副本，当然前提是缓存数据的metadata允许他们这么做。 可以使用如下的方法来使用缓存优化网络来提高整体的服务质量 减少带宽 降低延迟 减轻服务器负载 隐藏网络失败 译者注： 此处的减少带宽指的是，减少数据传输量（带宽使用）以提升服务的质量。 具体做法可参考文章Bandwidth and Data Transfer 摘抄其中一段： How can I reduce my “bandwidth usage”? 我怎么样才能降低我的带宽使用呢？ You cer ...

REST Resource Naming Guide 在REST中，主要的数据表现层称之为资源。使用一个健壮以及坚持使用同一个REST资源命名策略将是一个长期的最佳的设计决策。 在REST中，对于信息最关键的抽象即为资源。任何信息都可以被称为一个资源：一份文档或图像，一个临时的服务（例如：今天洛杉矶的天气），一个其他资源的集合，一个非虚拟化的物体（例如一个人）等等。换句话来说，任何可能成为作者超文本引用目标的概念都必须符合资源的定义。一个资源在概念上可映射为一组实体，而不是与任何特定时间点相映射的对应实体。 –Roy Fielding的博士论文 任何资源都可以是单个或者多个（一个集合）。就比如，对银行系统来说，一群顾客就是一个集合资源，一个顾客就是一个单个的资源。我们可以使用URI /customers 来标识一群顾客，同样可以使用URI /customers/{customerId} 来标识一个顾客。 一个资源同样可以包含子资源。例如，同样对银行系统来说，一个顾客（资源）可能含有多个银行账户（子资源），这些账户可以通过URN /customers/ ...

What is REST REST是REpresentational State Transfer（表述性状态传递）的缩写，是2000年由Roy Fielding在他论文中提出的一种适用于分布式超媒体系统（distributed hypermedia systems）的体系结构。 像任何其他架构风格一样，REST也有它自己的6个指导性约束，如果接口需要被称为RESTful，则必须满足这些约束。这些原则列在下面。 Guiding Principles of REST 客户端服务器模式（Client–server）：通过将用户界面问题与数据存储问题分离开来，我们可以提升跨多个平台的用户界面的可移植性，并通过简化服务器组件来提高可伸缩性。 无状态（Stateless）：从客户端到服务器的每个请求都必须包含处理请求所需的所有信息，并且不能利用服务器存储任何的上下文，因此，会话状态需要完全保留在客户端上。 可缓存（Cacheable）：缓存约束要求对请求响应中的数据隐式或明确标记为可缓存或不可缓存。如果响应是可缓存的，则客户端缓存有权重用该响应数据以用于以后等效的请求。 统一接口 ...

REST Architectural Constraints REST代表了Representational State Transfer（表述性状态传递）,一个由Roy Fielding在2000年创造的名词，是一种通过HTTP用来设计松散耦合应用的设计体系风格，通常被用来开发web service。REST并不强制任何有关如何在底层实现的规则，它仅仅提出了高层设计的方针并且让开发者去思考如何去实现。 在我最近一次的工作中，我为一家电信公司设计了2年的RESTful API、在这篇文章里，我将会分析我的一些从实际开发经验中总结的一些思考。你可能不同意其中的几点，但是这没关系，我乐意以开放的心态来与你讨论这些事。 让我们从标准设计的具体内容开始，来理解Roy Fielding到底想让我们如何去做。然后再来讨论一些我的想法使得你的RESTful API设计更加精益求精。 Architectural Constraints REST定义了6个可用于任何web服务（一个真正的RESTful API）的体系约束 统一接口 客户端-服务器模式 无状态 可缓存 分层系统 写满足需求的代码（可选） ...

0x00 原则 更小的通常更好，更小的数据类型占用更少的磁盘空间、内存和CPU缓存，就比如说要存储性别，可以使用unsigned tinyint类型，没必要使用int 简单就好，整数操作往往比字符操作或浮点数计算代价更低，比如我们要存银行卡余额，就尽量用整数，以分做单位，就比如56.89元存成int型写作5689分钱，浮点数要考虑精度，就上面银行卡余额的例子，如果存成double类型，精度丢失就容易导致钱对不上 不要用NULL，而且必须把字段定义为NOT NULL并且提供默认值，原因如下 如果定义表时没有指定NOT NULL，那么默认都是允许NULL的 处理NULL值只能采用IS NULL或IS NOT NULL，而不能采用=、in、<、<>、!=、not in这些操作符号，例如：where name!=’Jack’，如果存在name为NULL值的记录，查询结果就不会包含name为NULL值的记录 NULL值需要更多的存储空间且会拉低数据库的处理性能，无论是表还是索引中每行中的NULL的列都需要额外的空间来标识，增加数据库处理记录的复杂性，同等条件下，表中有较多空 ...

0x00 基准测试的目的及策略 基准测试（benchmark）主要用来观察系统在不同压力下的行为，评估系统的容量，就像你新买了个电脑或手机总要跑跑分跟别人比一比这样。 0x00 目的 重现异常行为 测试系统当前的运行状况和分析系统性能 模拟更高的负载，以确定当前系统会不会承受未来业务的增长 优化/调整后的性能对比，例如：新的索引会不会比旧的索引要快 0x01 策略 主要有两种策略集成式（full-stack）和单组件式（single-component） 集成式测试所应用的场景： 想知道整个系统真实的性能表现，比如一整套的web服务，到底当前的配置可以支撑得了多少的并发访问量 想知道某个应用具体是哪一部分拖累了性能，因为MySQL并不总是某个应用性能的瓶颈，有可能是你后端代码写的不行等等 单组件式测试所应用的场景： 调整/优化了一些代码，想快速知道调整后的效果 针对某一具体问题的测试 需要对不同的查询进行性能比较 测试对象： 如果能够在真实的数据集上执行重复的查询，那么得到的MySQL基准测试结果就应该是真实的，换句话说就是采用真实生产环境上的数据快照，当然这是不太可能的 ...

0x00 剖析查询性能 0x00 使用SHOW PROFILE SHOW PROFILE命令是从MySQL 5.1之后的版本引入的，这个工具默认是禁用的，可以使用如下命令将其打开 1SET profiling = 1; 这个工具会在服务器执行一条查询的时候，将性能信息记录到一张临时表，并且会记录你的SQL语句，并为其赋予一个单独的从1开始的整数标识符 首先我们执行一条查询 12mysql> select * from Country limit 20;..查询结果略.. 然后使用SHOW PROFILES语句来查看查询信息 123456789mysql> show profiles;+----------+------------+--------------------------------+| Query_ID | Duration | Query |+----------+------------+--------------------------------+| 1 | 0.00042900 | ...

0x00 前言 之前的服务器一直使用的lnmp自动化安装脚本来安装nginx, php-fpm等服务器环境，lnmp脚本有个缺点就是你可以一次性安装nginx, php-fpm, MySQL，但是你不能去分别安装这些服务，而且nginx貌似还不能自己加模块的样子。所以，喜欢瞎折腾的我边学边试了一把自己编译安装这些环境，记录一下，以便备忘。 0x01 编译安装php-fpm 因为从网上看到php7的执行效率比php5高了一倍的消息，所以给我的网站马上换上了php7，在这里编译安装的是php7.1.3 下载并解压php7 12wget http://cn2.php.net/get/php-7.1.3.tar.bz2/from/this/mirrortar xvf mirror && cd php-7.1.3 安装所必须的依赖 123456789101112131415apt-get install libkrb5-dev \libc-client2007e \libc-client2007e-dev \libcurl4 ...

0x00 前言 之前的服务器一直使用的lnmp自动化安装脚本来安装nginx, php-fpm等服务器环境，lnmp脚本有个缺点就是你可以一次性安装nginx, php-fpm, MySQL，但是你不能去分别安装这些服务，而且nginx貌似还不能自己加模块的样子。所以，喜欢瞎折腾的我边学边试了一把自己编译安装这些环境，记录一下，以便备忘。 0x01 编译安装Nginx 安装所必需的依赖： 12apt-get update && apt-get upgrade # 更新源和升级软件apt-get install gcc g++ make openssl libssl-dev libpcre3-dev # 安装必需的依赖 下载Nginx及ngx_cache_purge缓存模块（非必需）： 123456789cd ~ # 切换目录# 下载并解压nginx-1.10.3wget http://nginx.org/download/nginx-1.10.3.tar.gztar zxvf nginx-1.10.3.tar.gzcd nginx-1.10.3# 下载并解压ngx_ca ...

0x00 前言 撰写这篇文章的目的是为了指导实验室内的同学去学习和使用Git来进行项目的版本控制。文章内如有错误或不妥之处，请批评指正。 0x01 为什么要进行版本控制 协同合作 ，设想十几个人协同开发一个项目，如果没有版本控制系统，当你需要改动其中的某一个文件的时候，你就必需要告诉剩下的人，你在改动某一个文件，让其他人避免修改与你相同的文件，以免产生冲突，当然这是极其耗费精力而且不切实际的。如果使用了版本控制系统，每一个团队成员都可以在任何时间对任何文件毫无顾虑的进行修改，版本控制系统可以把之后所有的改动合并成一个共同的版本，不论是一个文件还是整个项目。 更好地存储代码，版本控制系统可以帮你分辨出你都改动了哪些代码，当你需要的时候，你可以随时查看你之前任意一个版本的代码，而且还可以获取到整个项目的快照 恢复之前的版本，如果你把你的代码改坏了，可以快速roll back回之前的版本 描述更改，运行通过简短的语句来对修改的部分进行描述 例如，以下为我在设计数据结构实训项目时的commit记录： 0x02 参考资料 为什么要使用版本控制系统