薛定饿

薛定饿 查看完整档案

上海编辑天津理工大学  |  软件工程 编辑唯品会  |  Java开发 编辑 github.com/sagexueqi 编辑
编辑

| |__ __ _
| '_ | | | |/ _` |
| |_) | |_| | (_| |
|_.__/ \__,_|\__, |

         |___/ 

个人动态

薛定饿 收藏了文章 · 2019-06-04

mysql锁以及实践总结

1. 锁分类

innodb中的锁分为S锁,即共享锁,另一种为X锁,排它锁,比如:

共享锁(S)

select * from supplier where id=5 lock in share mode;

排他锁(X)

select * from supplier where id=5 for update;

或者insert,delete,update语句,这都是排他锁

兼容性

这两种锁的兼容如下:

XS
XNN
SNY

意向锁

可以理解为属于S锁和X锁的父节点,即要获取S锁或者X锁的话,必须先提前获取意向锁,即IS或者IX锁,那综合起来看下,这两类锁的兼容情况如下

XSIXIS
XNNNN
SNYNY
IXNNYY
ISNYYY

隐式锁

也是醉了,为什么要搞这么多概念。。这种锁,可以认为不冲突的时候不加锁,这个时候的锁就是隐式锁,等遇到冲突了,该锁会升级为显示锁,还是通过一个例子来说明吧:


事务1(其中age是普通索引)

select * from test01 where age=21 for update;

我们看到mysql中其实是没有找到锁的:

事务2

insert into test01(id,name,age) values(8,'zzh',22);

这个时候由于[21,23)有gap锁,所以事务2会被阻塞住,这个时候再看mysql中的锁记录


可以看到一开始事务1虽然使用的是...for update,但是由于没有冲突所以加的是隐式锁,等到事务2开始导致有冲突存在,所以事务1的锁改为现实锁。

2.加锁分析与实践

具体在事务的不同隔离级别下,不同的场景加锁分析,在hedecheng加锁分析这篇文章已经讲解的非常详细了,这里就不再多说了。主要说下其他情况下总结的一些加锁分析。

2.1 插入意向锁(Insert Intention Locks)

先来看官网对该锁的解释


我们重点关注下红色的区域:在遇到冲突的时候,会在该索引所在的位置加S锁,而该共享锁又很容易导致死锁,官网中就有个例子来专门说明这种共享锁导致的死锁,即三个事务同事执行一条插入语句其中一个事务回滚导致死锁:


我们可以简单的把这种情况模仿一遍:


事务1

 insert into test01(id,name,age)values(12,"zzh",33);

事务2

 insert into test01(id,name,age)values(12,"zzh",33);

事务3

 insert into test01(id,name,age)values(12,"zzh",33);

如下图操作:


我们看下Mysql中锁的记录


其中这个就印证了在意向锁冲突的时候,请求加的是S锁,然后我们回滚事务1

事务1

rollback


这个时候我们看到事务2成功了,事务3出现死锁


我们可以从死锁日志中看到:

  • 事务2:等待锁模式为X的插入意向锁
  • 事务3:等待锁模式为X的插入意向锁;拥有锁模式为S的record lock
  • 暗含条件:事务2也拥有锁模式为S的record lock,这才导致了死锁,死锁日志会把最终成功获取锁了的事务已经拥有的锁不会打印出来

所以存在 事务2->事务3,事务3->事务2 死锁发生

官网中还要另一个类似的例子,这里就不多做分析了,原因类似。

下面我们看下另一种情况:


事务1(事务id=2944)

select * from test01 where age=21 for update;

事务2(事务id=2945)

insert into test01(id,name,age)values(2,"zzh",22);

事务3(事务id=2946)

select * from test01 where age=21 lock in share mode;

执行如下

mysql中锁记录


我们可以看到

  • 事务1:在primary key的(X,RECORD LOCK),在age_idx的(X,RECORD LOCK)
  • 事务2:在primay key 的(S,RECORD LOCK),这个就是我们前面讲到的,事务2在获取插入意向锁出现冲突,所以阻塞在了要获取(S,RECORD LOCK)
  • 事务3:在age_idx的(S,RECORD LOCK),

然后我们提交事务1
事务1

commit;

  • 事务2:加S锁成功,但是出现唯一键冲突,直接报错
  • 事务3:获取S锁成功,但是是在age_idx上,跟事务2不一样。

我们再重新执行事务1

事务1(事务id=29467)

select * from test01 where age=21 for update;

执行结果被阻塞:


我们看下mysql中的锁记录:

可以看到事务3拥有在age_idx的S锁,阻塞了事务1要获取的X锁,那这个时候我们提交事务3
事务3 commit;


我们发现事务1还处于阻塞的状态,看下mysql中的锁记录


这个时候明白了,事务2虽然执行失败,但是其由于插入意向锁冲突所加的S锁并未释放,所以会导致事务1还处于阻塞中。只有当我们提交了事务2,事务1才会真正执行。

2.2 select...for update

该语句加锁分为两种情况

  • 记录存在:如果是RC模式下,加的是(X,RECORD LOCK),RR 模式下,加的是(X,NEXT-KEY LOCK),该锁相互不兼容
  • 记录不存在:加(X,GAP)锁,并且该锁是兼容的,但是与Insert Intention Locks 不兼容,这个很容易导致死锁

2.2.1 不同索引之间等待出现死锁


事务1

select * from test01 where age=21 for update;

事务2

insert into test01(id,name,age)values(3,"zzh",22);

事务1

insert into test01(id,name,age)values(3,"zzh",100);

按如上顺序执行结果:


我们发现出现死锁,事务2被mysql回滚之后事务1执行成功。我们看下具体的死锁日志


通过死锁日志我们可以分析出来

  • 事务1: 拥有age_idx(X,NEXT-KEY LOCK),加插入意向锁存在冲突,所以等待id=3位置的(S,RECORD LOCK)
  • 事务2: 等待age_idx的插入意向锁(插入意向锁不只是在primary key上才有)
  • 暗含条件:事务2虽然在age_idx上等待插入意向锁,但是在id=3位置上加插入意向锁成功了,这才有了事务1在该位置加插入意向锁存在冲突

2.2.2 记录不存在导致的死锁


事务1(事务id=29684)

select * from test01 where age=21 for update;

事务2(事务id=29683)

select * from test01 where age=21 for update;

事务1

insert into test01(id,name,age)values(3,"zzh",22);

执行结果如下


可以看到

  • 事务1和事务2同时持有了age=22这个记录的gap锁,由于记录不存在,所以此时的gap锁兼容
  • 但是记录不存在兼容的gap锁和插入意向锁兵不兼容,所以事务1向age=22索引所请求的插入意向锁会等待。

事务2

insert into test01(id,name,age)values(3,"zzh",22);

由上面的分析同样得出事务2的等待有两种情况:

(1) 和事务1一样,等待age=22的插入意向锁,此时发现已经有事务1在等待该位置的插入意向锁,那就等待该位置的S锁

(2) 事务1虽然在age=22的插入意向锁等待,但是id=3的插入意向锁是加成功了,所以如果事务2在id=3这里等待插入意向锁的话,也会有冲突,那就等待该位置的S锁

所以,有这两种情况都会导致事务出现死锁,我们具体看下死锁日志:


我们看到:

  • 事务1在等待age=22位置的插入意向锁
  • 事务2在等待 id=3位置的S锁,也就是我们分析的第二种情况,同时事务2拥有age=22位置的gap锁

我们上面有分析,事务2的等待应该是有两种情况,而出现这两种情况的可能就是事务2的这条语句

insert into test01(id,name,age)values(3,"zzh",22);

我们了解到在记录不存在的时候,如果对此记录进行select...for update语句,该语句会对空位置加gap锁,这个会比较危险,如果我们的表用的是自增主键,而此时如果查询一个不存在的记录,那会把未来要插入的所有的空隙都加了gap锁,会导致以后表中无法在插入任何数据,这个极其危险。

3. 小结

本篇,我们介绍了mysql中的锁以及在实践中可能遇到的一些死锁,专门通过几个demo集中分析了一下,对于加锁的分析,在文中所提到的hedecheng的文章中,已经有很深的讲解,所以本文并没有对此总结。重点还是通过一些实际中用到的例子进行实际的分析一下整个过程。重点是插入意向锁和select...for update中的一些加锁的分析。下一篇来专门介绍下mysql的MVCC机制

查看原文

薛定饿 收藏了文章 · 2019-06-04

MySQL InnoDB引擎锁的总结

总结一下自己多年来对MySQL的相关知识,做个梳理。

本文用到的MySQL版本:5.7.22

为什么要锁

我们开的的各式各样系统中,系统运行需要CPU、内存、I/O、磁盘等等资源。但除了硬资源外,还有最为重要的软资源:数据

当人们访问操作我们的系统时,其实归根是对数据的查看与生产。那么对于同一份数据,如果多个用户同时对它查看、修改时会出现什么问题呢?这必然会带来竞争,而为了控制并发的读取、修改数据会对数据造成的不一致、错乱等问题,数据库引入了锁的机制。

当然锁的问题解决了并发访问数据的问题,而不可避免的会对系统的性能产生负面影响。总结一下各种锁的使用场景方便在实践中更好的运用它从而提升系统性能。

锁的种类

我们日常开发中用到最多的存储引擎是Innodb 与 MyISAM两种,而 Innodb 现在更多是首选,因此主要是对 Innodb 的说明,MyISAM 跟多是作为一个对比的角色。

MySQL的锁可以按照多种方式进行划分,这里使用最常用的两种方式进行划分:粒度与使用方式。

需要特别说明的是:乐观锁与悲观锁并不是数据库中实现的锁机制,是需要我们自己去实现的。它是一种思想,我们不仅仅可以用在MySQL中,其它地方有需要的也可以用到。而像悲观锁它也是利用数据库现有的机制进行实现的。下面先根据不同分类对说明相关概念。

按使用方式

乐观锁 机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。相对悲观锁而言,乐观锁更倾向于开发运用。

悲观锁 具有强烈的独占和排他特性。它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。

按粒度

表级锁 是MySQL中锁定粒度最大的一种锁,表示对当前操作的整张表加锁,它实现简单,资源消耗较少,被大部分MySQL引擎支持。最常使用的MyISAM与InnoDB都支持表级锁定。表级锁分为表共享读锁与表独占写锁。

行级锁 是Mysql中锁定粒度最细的一种锁,表示只针对当前操作的行进行加锁。行级锁能大大减少数据库操作的冲突。其加锁粒度最小,但加锁的开销也最大。行级锁分为共享锁 和 排他锁。

页级锁 是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快,但冲突多,行级冲突少,但速度慢。所以取了折衷的页级,一次锁定相邻的一组记录。BDB支持页级锁。

这里需要说明的是,悲观锁是一种思想,它的实现是使用了 共享锁与排他锁来实现的。因此悲观锁本身并不是MySQL实现的锁机制,它是我们造出来的一个概念。

另外,我看到很多文章在讲悲观锁时,只说排他锁是悲观锁机制,没有说共享锁是什么机制,而我认为共享锁也属于悲观锁,具体原因往后看。

InnoDB中加锁

MyISAM 相关的锁机制我就略过不总结了。

InnoDB 实现了两种类型的行锁,共享锁(S)与排他锁(X)。然后由于 InnoDB引擎又支持表级锁,所以它内部又有意向共享锁(IS)与意向排他锁(IX)。这两种表锁,都是InnoDB内部自动处理,换句话说我们写代码是无法控制也不需要控制的。我们能控制的是S与X锁。

为MySQL加锁

在日常操作中,UPDATEINSERTDELETE InnoDB会自动给涉及的数据集加排他锁,一般的 SELECT 一般是不加任何锁的。我们可以使用以下方式显示的为 SELECT 加锁。

  • 共享锁:select * from table_name where id =10 lock in share mode;
  • 排他锁:select * from table_name where id=10 for update;

那么什么时候该用共享锁什么时候用排他锁呢?
一般来讲,共享锁主要用在需要数据依存关系时来确认某行记录是否存在,并确保没有人对这个记录进行UPDATE或者DELETE操作(包括加锁的事物也只能读)。简单说就是大家都可以读数据,但是无法修改(更新或者删除),因此我认为::共享锁也是悲观锁::的一种实现。
排他锁是与共享锁相对应,自身加排他锁的事物能够自己发起修改操作,其它事物无法再对该数据加共享或者排他锁。

这里需要注意上面说到的一点,由于InnoDB引擎是行锁,不管我们在这条数据上加了共享锁还是排他锁,简单的select语句依然可以使用的,因为默认在InnoDB中select是不加锁的。

这里还有一点,上图中我们写到一个 间隙锁,这是什么东西?比如:当我们用范围条件而不是相等条件检索数据,并请求共享或排他锁时,InnoDB会给符合条件的已有数据的索引项加锁;对于键值在条件范围内但并不存在的记录,叫做“间隙(GAP)”,InnoDB也会对这个“间隙”加锁,这种锁机制就是所谓的间隙锁(Next-Key锁)。它存在的主要目的有一个是为了解决幻读问题,因为RR作为InnoDB的默认事物隔离级别,是存在幻读问题的,而我们在实际操作中确没有出现,就是因为这里做了处理。

关于乐观锁是如何加锁的,这个不同系统有不同的实现,简单来说,对每一个数据维护一个版本号,每次读取时把版本号读取出来,更新时版本号+1。然后更新时将读取的版本号作为条件,如果有其它事物更新了,那么必然会导致版本号变化,因为本次更新不会成功。这种机制最大程度的保证了并发。

查看锁情况

mysql> show status like 'innodb_row_lock%';
+-------------------------------+--------+
| Variable_name                 | Value  |
+-------------------------------+--------+
| Innodb_row_lock_current_waits | 0      |
| Innodb_row_lock_time          | 218276 |
| Innodb_row_lock_time_avg      | 18189  |
| Innodb_row_lock_time_max      | 51058  |
| Innodb_row_lock_waits         | 12     |
+-------------------------------+--------+
5 rows in set (0.05 sec)

上面的语句能够展示当前系统锁的情况,当系统锁争用比较严重的时候,Innodb_row_lock_waitsInnodb_row_lock_time_avg 的值会比较高。上面的数据是由于我做实验导致的。大家可以检查下自己的系统。

InnoDB什么时候会锁表

我们常常说InnoDB是行锁,但是这里介绍一下它锁表的情况。

InnoDB行锁是通过索引上的索引项来实现的,这一点MySQL与Oracle不同,后者是通过在数据中对相应数据行加锁来实现的。InnoDB这种行锁实现特点意味者:只有通过索引条件检索数据,InnoDB才会使用行级锁,否则,InnoDB将使用表锁!
在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。

这里我们实际演示一下,一来让大家了解如何测试锁情况,二来这样用例子也许更容易说明问题。表结构如下:

Create Table: CREATE TABLE `tb_user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(50) NOT NULL DEFAULT '',
  `age` mediumint(9) NOT NULL DEFAULT '1',
  `money` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=8 DEFAULT CHARSET=utf8

我们看当where条件不是索引时,如果加了排他锁,对这个表其它行记录也不能再加排他锁了,这明显就是锁住了整个表。而如果条件是索引字段,则它只会对where条件指定的行数据加锁,另一个事务可以对其它行数据加锁。

有些文章说只有表没有索引才会锁表,通过上面的实验,我觉得是不准确的。

总结

  • 悲观锁与乐观锁是一种思想,而不是数据库锁机制的实现;
  • InnoDB的行销是基于索引实现的,如果不通过索引访问数据,InnoDB会使用表锁;
  • 虽然根据标准InnoDB的默认事务隔离级别RR是存在幻读,但是通过间隙锁以及MVCC解决了幻读的问题;
  • 间隙锁的存在会导致并发插入问题,尽量减少范围查询;
  • InnoDB的索引设计非常重要。
查看原文

薛定饿 关注了专栏 · 2019-03-22

springCloud_Finchley

springCloud的Finchley版本开发总结

关注 5

薛定饿 收藏了文章 · 2018-09-13

高并发中nginx较优的配置

一、这里的优化主要是指对nginx的配置优化,一般来说nginx配置文件中对优化比较有作用的主要有以下几项:

  1. nginx进程数,建议按照cpu数目来指定,一般跟cpu核数相同或为它的倍数。

    worker_processes 8;
  2. 为每个进程分配cpu,上例中将8个进程分配到8个cpu,当然可以写多个,或者将一个进程分配到多个cpu。

    worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000 10000000;
  3. 下面这个指令是指当一个nginx进程打开的最多文件描述符数目,理论值应该是系统的最多打开文件数(ulimit-n)与nginx进程数相除,但是nginx分配请求并不是那么均匀,所以最好与ulimit -n的值保持一致。

    worker_rlimit_nofile 65535;
  4. 使用epoll的I/O模型,用这个模型来高效处理异步事件

    use epoll;
  5. 每个进程允许的最多连接数,理论上每台nginx服务器的最大连接数为worker_processes*worker_connections。

    worker_connections 65535;
  6. http连接超时时间,默认是60s,功能是使客户端到服务器端的连接在设定的时间内持续有效,当出现对服务器的后继请求时,该功能避免了建立或者重新建立连接。切记这个参数也不能设置过大!否则会导致许多无效的http连接占据着nginx的连接数,终nginx崩溃!

    keepalive_timeout 60;
  7. 客户端请求头部的缓冲区大小,这个可以根据你的系统分页大小来设置,一般一个请求的头部大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。

    client_header_buffer_size 4k;
  8. 下面这个参数将为打开文件指定缓存,默认是没有启用的,max指定缓存数量,建议和打开文件数一致,inactive是指经过多长时间文件没被请求后删除缓存。

    open_file_cache max=102400 inactive=20s;
  9. 下面这个是指多长时间检查一次缓存的有效信息。

    open_file_cache_valid 30s;
  10. open_file_cache指令中的inactive参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive时间内一次没被使用,它将被移除。

    open_file_cache_min_uses 1;
  11. 隐藏响应头中的有关操作系统和web server(Nginx)版本号的信息,这样对于安全性是有好处的。

    server_tokens off;
  12. 可以让sendfile()发挥作用。sendfile()可以在磁盘和TCP socket之间互相拷贝数据(或任意两个文件描述符)。Pre-sendfile是传送数据之前在用户空间申请数据缓冲区。之后用read()将数据从文件拷贝到这个缓冲区,write()将缓冲区数据写入网络。sendfile()是立即将数据从磁盘读到OS缓存。因为这种拷贝是在内核完成的,sendfile()要比组合read()和write()以及打开关闭丢弃缓冲更加有效(更多有关于sendfile)。

    sendfile on;
  13. 告诉nginx在一个数据包里发送所有头文件,而不一个接一个的发送。就是说数据包不会马上传送出去,等到数据包最大时,一次性的传输出去,这样有助于解决网络堵塞。

    tcp_nopush on; 
  14. 告诉nginx不要缓存数据,而是一段一段的发送--当需要及时发送数据时,就应该给应用设置这个属性,这样发送一小块数据信息时就不能立即得到返回值。

    tcp_nodelay on;

    比如:

    http { 
    server_tokens off; 
    sendfile on; 
    tcp_nopush on; 
    tcp_nodelay on; 
    ......
    }
  15. 客户端请求头部的缓冲区大小,这个可以根据系统分页大小来设置,一般一个请求头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。

    client_header_buffer_size 4k;
  16. 客户端请求头部的缓冲区大小,这个可以根据系统分页大小来设置,一般一个请求头的大小不会超过1k,不过由于一般系统分页都要大于1k,所以这里设置为分页大小。分页大小可以用命令getconf PAGESIZE取得。

    [root@test-huanqiu ~]# getconf PAGESIZE 
    4096

    但也有client_header_buffer_size超过4k的情况,但是client_header_buffer_size该值必须设置为“系统分页大小”的整倍数。

  17. 为打开文件指定缓存,默认是没有启用的,max 指定缓存数量,建议和打开文件数一致,inactive 是指经过多长时间文件没被请求后删除缓存。

    open_file_cache max=65535 inactive=60s;
  18. open_file_cache 指令中的inactive 参数时间内文件的最少使用次数,如果超过这个数字,文件描述符一直是在缓存中打开的,如上例,如果有一个文件在inactive 时间内一次没被使用,它将被移除。

    open_file_cache_min_uses 1;
  19. 指定多长时间检查一次缓存的有效信息。

    open_file_cache_valid 80s;

下面是一个使用的简单的nginx配置文件:

[root@dev-huanqiu ~]# cat /usr/local/nginx/conf/nginx.conf
user   www www;
worker_processes 8;
worker_cpu_affinity 00000001 00000010 00000100 00001000 00010000 00100000 01000000;
error_log   /www/log/nginx_error.log   crit;
pid         /usr/local/nginx/nginx.pid;
worker_rlimit_nofile 65535;
 
events
{
   use epoll;
   worker_connections 65535;
}
 
http
{
   include       mime.types;
   default_type   application/octet-stream;
 
   charset   utf-8;
 
   server_names_hash_bucket_size 128;
   client_header_buffer_size 2k;
   large_client_header_buffers 4 4k;
   client_max_body_size 8m;
 
   sendfile on;
   tcp_nopush     on;
 
   keepalive_timeout 60;
 
   fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2
                 keys_zone=TEST:10m
                 inactive=5m;
   fastcgi_connect_timeout 300;
   fastcgi_send_timeout 300;
   fastcgi_read_timeout 300;
   fastcgi_buffer_size 16k;
   fastcgi_buffers 16 16k;
   fastcgi_busy_buffers_size 16k;
   fastcgi_temp_file_write_size 16k;
   fastcgi_cache TEST;
   fastcgi_cache_valid 200 302 1h;
   fastcgi_cache_valid 301 1d;
   fastcgi_cache_valid any 1m;
   fastcgi_cache_min_uses 1;
   fastcgi_cache_use_stale error timeout invalid_header http_500; 
   open_file_cache max=204800 inactive=20s;
   open_file_cache_min_uses 1;
   open_file_cache_valid 30s; 
 
   tcp_nodelay on;
   
   gzip on;
   gzip_min_length   1k;
   gzip_buffers     4 16k;
   gzip_http_version 1.0;
   gzip_comp_level 2;
   gzip_types       text/plain application/x-javascript text/css application/xml;
   gzip_vary on;
 
   server
   {
     listen       8080;
     server_name   huan.wangshibo.com;
     index index.php index.htm;
     root   /www/html/;
 
     location /status
     {
         stub_status on;
     }
 
     location ~ .*\.(php|php5)?$
     {
         fastcgi_pass 127.0.0.1:9000;
         fastcgi_index index.php;
         include fcgi.conf;
     }
 
     location ~ .*\.(gif|jpg|jpeg|png|bmp|swf|js|css)$
     {
       expires       30d;
     }
 
     log_format   access   '$remote_addr - $remote_user [$time_local] "$request" '
               '$status $body_bytes_sent "$http_referer" '
               '"$http_user_agent" $http_x_forwarded_for';
     access_log   /www/log/access.log   access;
       }
}

二、关于FastCGI的几个指令

  1. 这个指令为FastCGI缓存指定一个路径,目录结构等级,关键字区域存储时间和非活动删除时间。

    fastcgi_cache_path /usr/local/nginx/fastcgi_cache levels=1:2 keys_zone=TEST:10m inactive=5m;
  2. 指定连接到后端FastCGI的超时时间。

    fastcgi_connect_timeout 300;
  3. 向FastCGI传送请求的超时时间,这个值是指已经完成两次握手后向FastCGI传送请求的超时时间。

    fastcgi_send_timeout 300;
  4. 接收FastCGI应答的超时时间,这个值是指已经完成两次握手后接收FastCGI应答的超时时间。

    fastcgi_read_timeout 300;
  5. 指定读取FastCGI应答第一部分 需要用多大的缓冲区,这里可以设置为fastcgi_buffers指令指定的缓冲区大小,上面的指令指定它将使用1个 16k的缓冲区去读取应答的第一部分,即应答头,其实这个应答头一般情况下都很小(不会超过1k),但是你如果在fastcgi_buffers指令中指 定了缓冲区的大小,那么它也会分配一个fastcgi_buffers指定的缓冲区大小去缓存。

    fastcgi_buffer_size 16k;
  6. 指定本地需要用多少和多大的缓冲区来 缓冲FastCGI的应答,如上所示,如果一个php脚本所产生的页面大小为256k,则会为其分配16个16k的缓冲区来缓存,如果大于256k,增大 于256k的部分会缓存到fastcgi_temp指定的路径中, 当然这对服务器负载来说是不明智的方案,因为内存中处理数据速度要快于硬盘,通常这个值 的设置应该选择一个你的站点中的php脚本所产生的页面大小的中间值,比如你的站点大部分脚本所产生的页面大小为 256k就可以把这个值设置为16 16k,或者4 64k 或者64 4k,但很显然,后两种并不是好的设置方法,因为如果产生的页面只有32k,如果用4 64k它会分配1个64k的缓冲区去缓存,而如果使用64 4k它会分配8个4k的缓冲区去缓存,而如果使用16 16k则它会分配2个16k去缓存页面,这样看起来似乎更加合理。

    fastcgi_buffers 16 16k;
  7. 这个指令我也不知道是做什么用,只知道默认值是fastcgi_buffers的两倍。

    fastcgi_busy_buffers_size 32k;
  8. 在写入fastcgi_temp_path时将用多大的数据块,默认值是fastcgi_buffers的两倍。

    fastcgi_temp_file_write_size 32k;
  9. 开启FastCGI缓存并且为其制定一个名称。个人感觉开启缓存非常有用,可以有效降低CPU负载,并且防止502错误。但是这个缓存会引起很多问题,因为它缓存的是动态页面。具体使用还需根据自己的需求。

    fastcgi_cache TEST
  10. 为指定的应答代码指定缓存时间,如上例中将200,302应答缓存一小时,301应答缓存1天,其他为1分钟。

    fastcgi_cache_valid 200 302 1h;
    fastcgi_cache_valid 301 1d;
    fastcgi_cache_valid any 1m;
  11. 缓存在fastcgi_cache_path指令inactive参数值时间内的最少使用次数,如上例,如果在5分钟内某文件1次也没有被使用,那么这个文件将被移除。

    fastcgi_cache_min_uses 1;
  12. 不知道这个参数的作用,猜想应该是让nginx知道哪些类型的缓存是没用的。

    fastcgi_cache_use_stale error timeout invalid_header http_500;

    ----By 微风

查看原文

薛定饿 收藏了文章 · 2018-08-07

后管模版整理

Bootstrap

Adminlte
项目:https://github.com/almasaeed2...
演示:https://adminlte.io/themes/Ad...
0_1532963333268_admin-adminlte.png

SB Admin
项目:https://github.com/BlackrockD...
演示:https://blackrockdigital.gith...
0_1532963355592_admin-start-bootstrap.png

Gentelella Admin
项目:https://github.com/puikinsh/g...
演示:https://colorlib.com/polygon/...
0_1532963370697_admin-gentelella-alela.png

Vali Admin
项目:https://github.com/pratikbors...
演示:http://pratikborsadiya.in/val...
0_1532963391407_admin-vali.png

ModularAdmin
项目:https://github.com/modularcod...
演示:https://gurayyarar.github.io/...
0_1532963413895_admin-modular-admin.png

Metis
项目:https://github.com/puikinsh/B...
演示:https://colorlib.com/polygon/...
0_1532963434724_admin-metis.png

Ace
项目:https://github.com/bopoda/ace
演示:http://ace.jeka.by/
0_1532963453654_admin-ace-admin.png

Light Bootstrap Dashboard
项目:https://github.com/creativeti...
演示:http://demos.creative-tim.com...
0_1532963476875_admin-light-bootstrap.png

Material Dashboard
项目:https://github.com/creativeti...
演示:http://demos.creative-tim.com...
0_1532963504324_admin-material-dashboard.png

Clearmin
项目:https://github.com/paomedia/c...
演示:http://cm.paomedia.com/
0_1532963519587_admin-clearmin.png

Vue

Element Admin
项目:https://github.com/PanJiaChen...
演示:https://panjiachen.github.io/...
0_1532963547572_admin-vue-element.png

Vue-Bulma
项目:https://github.com/vue-bulma/...
演示:https://admin.vuebulma.com/
0_1532963569652_admin-vue-bulma.png

Iview-Admin
项目:https://github.com/iview/ivie...
演示:https://admin.iviewui.com
0_1533140586135_admin-vue-iview.png

Vuestic-Admin
项目:https://github.com/epicmaxco/...
演示:https://vuestic.epicmax.co/
0_1532963626552_admin-vuestic.png

D2-Admin
项目:https://github.com/d2-project...
演示:https://fairyever.gitee.io/d2...
0_1532963643969_admin-d2-admin.png

Vue-Material-Admin
项目:https://github.com/tookit/vue...
演示:http://vma.isocked.com/
0_1532963667511_amin-vue-material-admin.png

Angularjs

Rdash-Angular
项目:https://github.com/rdash/rdas...
演示:http://rdash.github.io/
0_1532963688068_admin-rdash-angular.png

Ng-Admin
项目:https://github.com/marmelab/n...
演示:https://marmelab.com/ng-admin...
0_1532963706842_admin-ng-admin.png

Angular

Ngx-Admin
项目:https://github.com/akveo/ngx-...
演示:http://akveo.com/ngx-admin/
0_1532963730455_admin-ngx-admin.png

Ng-Alain
项目:https://github.com/cipchk/ng-...
演示:https://cipchk.github.io/ng-a...
0_1532963756605_admin-ng-alain.png

SB-Admin-BS4-Angular6
项目:https://github.com/start-angu...

Angular-Material
项目:https://github.com/flatlogic/...
演示:http://flatlogic.github.io/an...
0_1532963780970_admin-angular-material.png

React

React-Admin
项目:https://github.com/marmelab/r...
演示:https://marmelab.com/react-ad...
0_1532963804010_admin-react-admin.png

Ant-Design-Pro
项目:https://github.com/ant-design...
演示:https://preview.pro.ant.design/
0_1532963835903_admin-ant-design-pro.png

SB-Admin-React
项目:https://github.com/start-reac...

React-Material-Admin
项目:https://github.com/rafaelhz/r...
演示:https://rafaelhz.github.io/re...
0_1532963864685_admin-react-material-admin.png

React-Webpack-Skeleton
项目:https://github.com/knledg/rea...
演示:http://knledg.github.io/
0_1532963877718_admin-react-webpack-skeleton.png

Bear-Admin
项目:https://github.com/huzzbuzz/b...
演示:http://huzzbuzz.coding.me/bea...
0_1532963900199_admin-bear-admin.png

React-Director-Admin
项目:https://github.com/MacKentoch...
演示:http://mackentoch.github.io/r...
0_1532963931295_admin-react-director.png

Admin-On-Rest
项目:https://github.com/marmelab/a...
演示:https://marmelab.com/admin-on...
0_1532963955700_admin-on-rest-demo.png

原文链接: http://www.bestvist.com/p/57

查看原文

薛定饿 赞了文章 · 2018-08-07

后管模版整理

Bootstrap

Adminlte
项目:https://github.com/almasaeed2...
演示:https://adminlte.io/themes/Ad...
0_1532963333268_admin-adminlte.png

SB Admin
项目:https://github.com/BlackrockD...
演示:https://blackrockdigital.gith...
0_1532963355592_admin-start-bootstrap.png

Gentelella Admin
项目:https://github.com/puikinsh/g...
演示:https://colorlib.com/polygon/...
0_1532963370697_admin-gentelella-alela.png

Vali Admin
项目:https://github.com/pratikbors...
演示:http://pratikborsadiya.in/val...
0_1532963391407_admin-vali.png

ModularAdmin
项目:https://github.com/modularcod...
演示:https://gurayyarar.github.io/...
0_1532963413895_admin-modular-admin.png

Metis
项目:https://github.com/puikinsh/B...
演示:https://colorlib.com/polygon/...
0_1532963434724_admin-metis.png

Ace
项目:https://github.com/bopoda/ace
演示:http://ace.jeka.by/
0_1532963453654_admin-ace-admin.png

Light Bootstrap Dashboard
项目:https://github.com/creativeti...
演示:http://demos.creative-tim.com...
0_1532963476875_admin-light-bootstrap.png

Material Dashboard
项目:https://github.com/creativeti...
演示:http://demos.creative-tim.com...
0_1532963504324_admin-material-dashboard.png

Clearmin
项目:https://github.com/paomedia/c...
演示:http://cm.paomedia.com/
0_1532963519587_admin-clearmin.png

Vue

Element Admin
项目:https://github.com/PanJiaChen...
演示:https://panjiachen.github.io/...
0_1532963547572_admin-vue-element.png

Vue-Bulma
项目:https://github.com/vue-bulma/...
演示:https://admin.vuebulma.com/
0_1532963569652_admin-vue-bulma.png

Iview-Admin
项目:https://github.com/iview/ivie...
演示:https://admin.iviewui.com
0_1533140586135_admin-vue-iview.png

Vuestic-Admin
项目:https://github.com/epicmaxco/...
演示:https://vuestic.epicmax.co/
0_1532963626552_admin-vuestic.png

D2-Admin
项目:https://github.com/d2-project...
演示:https://fairyever.gitee.io/d2...
0_1532963643969_admin-d2-admin.png

Vue-Material-Admin
项目:https://github.com/tookit/vue...
演示:http://vma.isocked.com/
0_1532963667511_amin-vue-material-admin.png

Angularjs

Rdash-Angular
项目:https://github.com/rdash/rdas...
演示:http://rdash.github.io/
0_1532963688068_admin-rdash-angular.png

Ng-Admin
项目:https://github.com/marmelab/n...
演示:https://marmelab.com/ng-admin...
0_1532963706842_admin-ng-admin.png

Angular

Ngx-Admin
项目:https://github.com/akveo/ngx-...
演示:http://akveo.com/ngx-admin/
0_1532963730455_admin-ngx-admin.png

Ng-Alain
项目:https://github.com/cipchk/ng-...
演示:https://cipchk.github.io/ng-a...
0_1532963756605_admin-ng-alain.png

SB-Admin-BS4-Angular6
项目:https://github.com/start-angu...

Angular-Material
项目:https://github.com/flatlogic/...
演示:http://flatlogic.github.io/an...
0_1532963780970_admin-angular-material.png

React

React-Admin
项目:https://github.com/marmelab/r...
演示:https://marmelab.com/react-ad...
0_1532963804010_admin-react-admin.png

Ant-Design-Pro
项目:https://github.com/ant-design...
演示:https://preview.pro.ant.design/
0_1532963835903_admin-ant-design-pro.png

SB-Admin-React
项目:https://github.com/start-reac...

React-Material-Admin
项目:https://github.com/rafaelhz/r...
演示:https://rafaelhz.github.io/re...
0_1532963864685_admin-react-material-admin.png

React-Webpack-Skeleton
项目:https://github.com/knledg/rea...
演示:http://knledg.github.io/
0_1532963877718_admin-react-webpack-skeleton.png

Bear-Admin
项目:https://github.com/huzzbuzz/b...
演示:http://huzzbuzz.coding.me/bea...
0_1532963900199_admin-bear-admin.png

React-Director-Admin
项目:https://github.com/MacKentoch...
演示:http://mackentoch.github.io/r...
0_1532963931295_admin-react-director.png

Admin-On-Rest
项目:https://github.com/marmelab/a...
演示:https://marmelab.com/admin-on...
0_1532963955700_admin-on-rest-demo.png

原文链接: http://www.bestvist.com/p/57

查看原文

赞 279 收藏 236 评论 11

薛定饿 收藏了文章 · 2018-07-18

基于Redis实现分布式锁实战

背景

在很多互联网产品应用中,有些场景需要加锁处理,比如:秒杀,全局递增ID,楼层生成等等。大部分的解决方案是基于DB实现的,Redis为单进程单线程模式,采用队列模式将并发访问变成串行访问,且多客户端对Redis的连接并不存在竞争关系。其次Redis提供一些命令SETNX,GETSET,可以方便实现分布式锁机制。

Redis命令介绍

使用Redis实现分布式锁,有两个重要函数需要介绍

SETNX命令(SET if Not eXists)
语法:
SETNX key value
功能:
当且仅当 key 不存在,将 key 的值设为 value ,并返回1;若给定的 key 已经存在,则 SETNX 不做任何动作,并返回0。

GETSET命令
语法:
GETSET key value
功能:
将给定 key 的值设为 value ,并返回 key 的旧值 (old value),当 key 存在但不是字符串类型时,返回一个错误,当key不存在时,返回nil。

GET命令
语法:
GET key
功能:
返回 key 所关联的字符串值,如果 key 不存在那么返回特殊值 nil 。

DEL命令
语法:
DEL key [KEY …]
功能:
删除给定的一个或多个 key ,不存在的 key 会被忽略。

兵贵精,不在多。分布式锁,我们就依靠这四个命令。但在具体实现,还有很多细节,需要仔细斟酌,因为在分布式并发多进程中,任何一点出现差错,都会导致死锁,hold住所有进程。

加锁实现

SETNX 可以直接加锁操作,比如说对某个关键词foo加锁,客户端可以尝试
SETNX foo.lock <current unix time>

如果返回1,表示客户端已经获取锁,可以往下操作,操作完成后,通过
DEL foo.lock

命令来释放锁。
如果返回0,说明foo已经被其他客户端上锁,如果锁是非堵塞的,可以选择返回调用。如果是堵塞调用调用,就需要进入以下个重试循环,直至成功获得锁或者重试超时。理想是美好的,现实是残酷的。仅仅使用SETNX加锁带有竞争条件的,在某些特定的情况会造成死锁错误。

处理死锁

在上面的处理方式中,如果获取锁的客户端端执行时间过长,进程被kill掉,或者因为其他异常崩溃,导致无法释放锁,就会造成死锁。所以,需要对加锁要做时效性检测。因此,我们在加锁时,把当前时间戳作为value存入此锁中,通过当前时间戳和Redis中的时间戳进行对比,如果超过一定差值,认为锁已经时效,防止锁无限期的锁下去,但是,在大并发情况,如果同时检测锁失效,并简单粗暴的删除死锁,再通过SETNX上锁,可能会导致竞争条件的产生,即多个客户端同时获取锁。

C1获取锁,并崩溃。C2和C3调用SETNX上锁返回0后,获得foo.lock的时间戳,通过比对时间戳,发现锁超时。
C2 向foo.lock发送DEL命令。
C2 向foo.lock发送SETNX获取锁。
C3 向foo.lock发送DEL命令,此时C3发送DEL时,其实DEL掉的是C2的锁。
C3 向foo.lock发送SETNX获取锁。

此时C2和C3都获取了锁,产生竞争条件,如果在更高并发的情况,可能会有更多客户端获取锁。所以,DEL锁的操作,不能直接使用在锁超时的情况下,幸好我们有GETSET方法,假设我们现在有另外一个客户端C4,看看如何使用GETSET方式,避免这种情况产生。

C1获取锁,并崩溃。C2和C3调用SETNX上锁返回0后,调用GET命令获得foo.lock的时间戳T1,通过比对时间戳,发现锁超时。
C4 向foo.lock发送GESET命令,
GETSET foo.lock <current unix time>
并得到foo.lock中老的时间戳T2

如果T1=T2,说明C4获得时间戳。
如果T1!=T2,说明C4之前有另外一个客户端C5通过调用GETSET方式获取了时间戳,C4未获得锁。只能sleep下,进入下次循环中。

现在唯一的问题是,C4设置foo.lock的新时间戳,是否会对锁产生影响。其实我们可以看到C4和C5执行的时间差值极小,并且写入foo.lock中的都是有效时间错,所以对锁并没有影响。
为了让这个锁更加强壮,获取锁的客户端,应该在调用关键业务时,再次调用GET方法获取T1,和写入的T0时间戳进行对比,以免锁因其他情况被执行DEL意外解开而不知。以上步骤和情况,很容易从其他参考资料中看到。客户端处理和失败的情况非常复杂,不仅仅是崩溃这么简单,还可能是客户端因为某些操作被阻塞了相当长时间,紧接着 DEL 命令被尝试执行(但这时锁却在另外的客户端手上)。也可能因为处理不当,导致死锁。还有可能因为sleep设置不合理,导致Redis在大并发下被压垮。最为常见的问题还有

GET返回nil时应该走那种逻辑?

第一种走超时逻辑
C1客户端获取锁,并且处理完后,DEL掉锁,在DEL锁之前。C2通过SETNX向foo.lock设置时间戳T0 发现有客户端获取锁,进入GET操作。
C2 向foo.lock发送GET命令,获取返回值T1(nil)。
C2 通过T0>T1+expire对比,进入GETSET流程。
C2 调用GETSET向foo.lock发送T0时间戳,返回foo.lock的原值T2
C2 如果T2=T1相等,获得锁,如果T2!=T1,未获得锁。

第二种情况走循环走setnx逻辑
C1客户端获取锁,并且处理完后,DEL掉锁,在DEL锁之前。C2通过SETNX向foo.lock设置时间戳T0 发现有客户端获取锁,进入GET操作。
C2 向foo.lock发送GET命令,获取返回值T1(nil)。
C2 循环,进入下一次SETNX逻辑

两种逻辑貌似都是OK,但是从逻辑处理上来说,第一种情况存在问题。当GET返回nil表示,锁是被删除的,而不是超时,应该走SETNX逻辑加锁。走第一种情况的问题是,正常的加锁逻辑应该走SETNX,而现在当锁被解除后,走的是GETST,如果判断条件不当,就会引起死锁,很悲催,我在做的时候就碰到了,具体怎么碰到的看下面的问题

GETSET返回nil时应该怎么处理?

C1和C2客户端调用GET接口,C1返回T1,此时C3网络情况更好,快速进入获取锁,并执行DEL删除锁,C2返回T2(nil),C1和C2都进入超时处理逻辑。
C1 向foo.lock发送GETSET命令,获取返回值T11(nil)。
C1 比对C1和C11发现两者不同,处理逻辑认为未获取锁。
C2 向foo.lock发送GETSET命令,获取返回值T22(C1写入的时间戳)。
C2 比对C2和C22发现两者不同,处理逻辑认为未获取锁。

此时C1和C2都认为未获取锁,其实C1是已经获取锁了,但是他的处理逻辑没有考虑GETSET返回nil的情况,只是单纯的用GET和GETSET值就行对比,至于为什么会出现这种情况?一种是多客户端时,每个客户端连接Redis的后,发出的命令并不是连续的,导致从单客户端看到的好像连续的命令,到Redis server后,这两条命令之间可能已经插入大量的其他客户端发出的命令,比如DEL,SETNX等。第二种情况,多客户端之间时间不同步,或者不是严格意义的同步。

时间戳的问题

我们看到foo.lock的value值为时间戳,所以要在多客户端情况下,保证锁有效,一定要同步各服务器的时间,如果各服务器间,时间有差异。时间不一致的客户端,在判断锁超时,就会出现偏差,从而产生竞争条件。
锁的超时与否,严格依赖时间戳,时间戳本身也是有精度限制,假如我们的时间精度为秒,从加锁到执行操作再到解锁,一般操作肯定都能在一秒内完成。这样的话,我们上面的CASE,就很容易出现。所以,最好把时间精度提升到毫秒级。这样的话,可以保证毫秒级别的锁是安全的。

分布式锁的问题

1:必要的超时机制:获取锁的客户端一旦崩溃,一定要有过期机制,否则其他客户端都降无法获取锁,造成死锁问题。
2:分布式锁,多客户端的时间戳不能保证严格意义的一致性,所以在某些特定因素下,有可能存在锁串的情况。要适度的机制,可以承受小概率的事件产生。
3:只对关键处理节点加锁,良好的习惯是,把相关的资源准备好,比如连接数据库后,调用加锁机制获取锁,直接进行操作,然后释放,尽量减少持有锁的时间。
4:在持有锁期间要不要CHECK锁,如果需要严格依赖锁的状态,最好在关键步骤中做锁的CHECK检查机制,但是根据我们的测试发现,在大并发时,每一次CHECK锁操作,都要消耗掉几个毫秒,而我们的整个持锁处理逻辑才不到10毫秒,玩客没有选择做锁的检查。
5:sleep学问,为了减少对Redis的压力,获取锁尝试时,循环之间一定要做sleep操作。但是sleep时间是多少是门学问。需要根据自己的Redis的QPS,加上持锁处理时间等进行合理计算。
6:至于为什么不使用Redis的muti,expire,watch等机制,可以查一参考资料,找下原因。
7:想要深入系统了解分布式技术的话,我在这里给大家推荐一个架构方面的交流学习群:650385180,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,相信对于已经工作和遇到技术瓶颈的码友,在这个群里会有你需要的内容。

锁测试数据

未使用sleep
第一种,锁重试时未做sleep。单次请求,加锁,执行,解锁时间

clipboard.png

可以看到加锁和解锁时间都很快,当我们使用

ab -n1000 -c100 'http://sandbox6.wanke.etao.co...'
AB 并发100累计1000次请求,对这个方法进行压测时。

clipboard.png

我们会发现,获取锁的时间变成,同时持有锁后,执行时间也变成,而delete锁的时间,将近10ms时间,为什么会这样?
1:持有锁后,我们的执行逻辑中包含了再次调用Redis操作,在大并发情况下,Redis执行明显变慢。
2:锁的删除时间变长,从之前的0.2ms,变成9.8ms,性能下降近50倍。
在这种情况下,我们压测的QPS为49,最终发现QPS和压测总量有关,当我们并发100总共100次请求时,QPS得到110多。当我们使用sleep时

使用Sleep时

单次执行请求时

clipboard.png

我们看到,和不使用sleep机制时,性能相当。当时用相同的压测条件进行压缩时

clipboard.png

获取锁的时间明显变长,而锁的释放时间明显变短,仅是不采用sleep机制的一半。当然执行时间变成就是因为,我们在执行过程中,重新创建数据库连接,导致时间变长的。同时我们可以对比下Redis的命令执行压力情况

clipboard.png

上图中细高部分是为未采用sleep机制的时的压测图,矮胖部分为采用sleep机制的压测图,通上图看到压力减少50%左右,当然,sleep这种方式还有个缺点QPS下降明显,在我们的压测条件下,仅为35,并且有部分请求出现超时情况。不过综合各种情况后,我们还是决定采用sleep机制,主要是为了防止在大并发情况下把Redis压垮,很不行,我们之前碰到过,所以肯定会采用sleep机制。

文章转载自CSDN:https://blog.csdn.net/ugg/art...

参考资料

http://www.worlduc.com/FileSy...
http://redis.io/commands/setnx
http://www.blogjava.net/caoji...

查看原文

薛定饿 收藏了文章 · 2018-07-16

通往架构师路上的经验总结

前言:

我先介绍一下我的新同事,据说他是美国篮球运动员詹姆斯的死忠粉,公司好多同事都这么叫他James,有8年开发经验的架构师,之前在AL待过,我一听说是AL的,啧啧啧........,就有种莫名的种亲切感,就立马找新同事聊了起来。我们在空余的时间聊了很久,也聊了好多。毕竟之前都在AL待过,感觉话题还是有的。
在聊天过程中,我们也聊到了他为什么离开AL,也聊到了他在成为架构师的道路上的辛酸历程,聊过后,才发现,离开AL的原因和他的架构师之路和我的很是相似。都是经历不知多少个日夜磨砺出来的辛酸历程。现在回想过去,在看现在的自己,感觉之前的辛酸都是值得的。
好了,我在这里就不跟大家扯这么多了,今天的这篇文章,主要是我们两在聊天讨论的过程中,产生了很多在成为架构师的过程中的一些共鸣点,既然我们所经历的点有共鸣,那么我相信跟大家的也相差不大,所以,这篇文章仅供大家参考学习以及在成为架构师的道路上应该掌握的知识点和经验。相信你在看完这篇文章后,你有一个明确的目标以及一个通往架构师路上正确的方向。

困扰架构师日常问题

  1. 架构师应不应该写代码
  2. 为什么别人的系统总是那么烂
  3. 成为架构师最困难的门槛是什么?
  4. 如何更高效的学习?
  5. 面对目前流行的技术不知如何下手?
  6. 一家公司待久了,过得很安逸,但跳槽时面试碰壁?
  7. 觉得现在的技术基础感觉到很扎实,但就是自己的技术提升不上?
  8. 觉得自己很牛B,一般需求都能搞定,但是所学的知识点没有系统化,很难在技术领域继续突破?
  9. 现在觉得自己技术还可以,但就是薪资涨不上去?

以上这几点,做为开发人员的你们,有遇到过么?有为自己想过么?有细心仔细的去解决过这些问题么?有深刻的想过么?虽然这几个问题很简单,但对于我们在开发路上,是有非常重要的帮助的。

1:架构师应不应该写代码
合格的程序员对于明确分配的任务会完成的很好,但是大部分情况下“架构”这个词意味着架构师并不会涉及太多细节,架构图和代码实现之间总还是有些距离,你无法保证所有人都会正确的理解你的设计,或者是程序员写代码时遇到障碍时会立刻想出足够优雅的解决方案。
在我看来,写代码的架构师更像是在做后勤保障的工作:在代码中第一时间发现可能存在的问题,向其他人提出警告,或是给予其他人改进的意见,必要的时候或是给其他人演示一下正确的姿势。
大部分情况下我作为架构师并不需要揽下“核心模块”开发这种工作,毕竟我能调配的时间太零散了,效率难以保证,很多人在专注的情况下比我做的好很多,我只需要保持大局观需要适度参与就可以了。
总的来说,架构师和程序员在某些方面上有点像产品经理和用户的关系,大部分程序员并不会主动告诉你他们想要什么、哪里需要优化,甚至自己也不知道这些。想要做出好的产品,捷径之一就是跟用户做同样的事情。

2:为什么别人的系统总是那么烂
很多程序员解决问题的能力很强,说要解决一个什么问题,下午就能写出几百行代码把功能实现了。但是做出来的东西有种少考虑了什么东西的感觉。大部分程序都能实现功能,但是如果把“时间”这个也作为一个考虑的维度的话,就会意识到一个合格的项目需要考虑更多的东西:更通用的使用方式、易于理解的文档、简单而易于扩展的设计,等等。
很多公司应该都会有一些遗留系统,它们庞大、笨重、难用、几乎无法维护,所有人都在抱怨这些系统,并且每天都在想方设法换掉那些遗留系统。但是一段时间过去之后,又会发现身边的新人又开始吐槽当时替代遗留系统的那个系统了。

3:成为架构师最困难的门槛是什么?
很多人自称架构师的人跟你讲一个架构时简直滔滔不绝,各种技术名词像是说相声一样从他嘴里说出来,三句话不离高并发大数据,但是稍微追问一下,就会发现很多基本概念的缺失,例如自称精通高并发的人说不清楚他所谓的高并发系统的瓶颈在哪里,自称精通架构设计的人说不明白他的系统怎么保证高可用,自称超大数据量的系统实际上只有不到100万条数据,等等。
架构师虽然听起来很高大上,但本质上仍然是工程师,不是科学家,也不是忽悠人的江湖骗子。学习再多,也需要实践落地。设计架构方案更多的是在做一些抽象和权衡:把复杂的需求抽象成简单的模型,从功能、性能、可用性、研发成本等等方面规划如何构建一个系统,这些内容需要更多的实践练习。

4:如何更高效的学习?
大多数人每天能留给自己学习的时间有限,这个阶段如何提升学习效率就成了要解决的重点。
说说自己提升学习效率的心得,其实非常简单:体系化的学习。
在重复了几次痛苦的学习-梳理过程后,再去看一些独立的文章或者资料往往会事半功倍,因为能在体系内找到相对应的知识,甚至有时候一本书里一页只需要看一句话,点破那层窗户纸,就可以掌握新的知识。
跟很多人一样,刚毕业时我觉得作为程序员,只要努力,加上少许天赋便可以获得一些成绩。
工作一段时间后,对自己和其他人的认识也越来越清晰,逐渐的发现程序员之间的差距或许比人和猴子之间的差距还大,接受这个事实这让我郁闷了很久。
再过一段时间,发现自己已经能够客观的评价自己的能力,也意识到了距离并不是那么重要,只要想办法跑的更快,就足够了。

5:面对目前流行的技术不知如何下手?
第一,根据自己目前工作中所用到的技术,有目的性的学习;
第二,可以根据各大互联网公司的招聘要求,有选择性地进行规划学习;
第三,可以参照文章尾部Java架构师所具备知识点,上面有从源码到分布式到微服务到并发等,是十多年的一群有经验的老师整理出来的。

6:一家公司待久了,过得很安逸,但跳槽时面试碰壁?
很多程序员有这样的情况,因为一直处于自己的舒适区,每天写的是自己熟悉的业务代码,更多的做的是crud的工作,技术上没有挑战性,觉得生活也还可以。但是一旦跳出这个舒适区,就会很难适应,不知所措,因为外面新的技术太多,自己完全跟不上技术的步伐,这时候需要梳理一下自己目前所欠缺的点,有针对性地进行提高。

7:觉得现在的技术基础感觉到很扎实,但就是自己的技术提升不上?
这种技术扎实更多的是基础,比如javase,javaee等,并不能适应一线互联网公司的技术体系,比如分布式,微服务这块。技术提升不上是因为自己没有接触过相关的项目,以前那种基础知识网上还一大篇,但是越往上走资料越少,好的资料就越少,而且越往上如果没有引路人更加举步维艰。

8:觉得自己很牛B,一般需求都能搞定,但是所学的知识点没有系统化,很难在技术领域继续突破?
这里的一般需求,更多的应该是在单机环境之下的crud操作,项目没有太多难度,顶多是业务上的分析复杂一些,技术用到了一些主流的技术,比如dubbo,也仅仅停留在api的使用层面,不了解其原理,而且与dubbo相关的其他技术分支并没有很好的拓展,所以感觉很难突破。

9:现在觉得自己技术还可以,但就是薪资涨不上去?
需要弄清楚薪资由什么决定,是由你的价值决定,而你的价值取决于你的技术能力,如果你的技术能力一直停留在crud的层面,肯定会上不去,你需要做的是突破技术瓶颈。(我相信这一点,是大多数开发人员会首先考虑到的问题)。

经过以上的几个问题的总结,你们有一点点理解了么?有什么感触没?没有?那么你们继续往下看。

程序员应有的几个阶段

  • 第一阶段----三年

我认为三年对于程序员来说是第一个门槛,这个阶段将会淘汰掉一批不适合写代码的人。这一阶段,我们走出校园,迈入社会,成为一名程序员,正式从书本上的内容迈向真正的企业级开发。我们知道如何团队协作、如何使用项目管理工具、项目版本如何控制、我们写的代码如何测试如何在线上运行等等,积累了一定的开发经验,也对代码有了一定深入的认识,是一个比较纯粹的Coder的阶段。

  • 第二阶段----五年

五年又是区分程序员的第二个门槛。有些人在三年里,除了完成工作,在空余时间基本不会研究别的东西,这些人永远就是个Coder,年纪大一些势必被更年轻的人给顶替;有些人在三年里,除了写代码之外,还热衷于研究各种技术实现细节、看了N多好书、写一些博客、在Github上分享技术,这些人在五年后必然具备在技术上独当一面的能力并且清楚自己未来的发展方向,从一个Coder逐步走向系统分析师或是架构师,成为项目组中不可或缺的人物。

  • 第三阶段----十年

十年又是另一个门槛了,转行或是继续做一名程序员就在这个节点上。如果在前几年就抱定不转行的思路并且为之努力的话,那么在十年的这个节点上,有些人必然成长为一名对行业有着深入认识、对技术有着深入认识、能从零开始对一个产品进行分析的程序员,这样的人在公司基本担任的都是CTO、技术专家、首席架构师等最关键的职位,这对于自己绝对是一件荣耀的事,当然老板在经济上也绝不会亏待你。

我认为,随着你工作年限的增长、对生活对生命认识的深入,应当不断思考三个问题:

  • 我到底适不适合当一名程序员?
  • 我到底应不应该一辈子以程序员为职业?
  • 我对编程到底持有的是一种什么样的态度,是够用就好呢还是不断研究?

最终,明确自己的职业规划,对自己的规划负责并为之努力。

架构师所具备的知识点

一:常见模式与工具

学习Java技术体系,设计模式,流行的框架与组件是必不可少的:
  • 常见的设计模式,编码必备
  • Spring5,做应用必不可少的最新框架
  • MyBatis,玩数据库必不可少的组件

clipboard.png

二:工程化与工具

工欲善其事必先利其器,不管是小白,还是资深开发,玩Java技术体系,选择好的工具,提升开发效率和团队协作效率,是必不可少的:
  • Maven,项目管理
  • Jenkins,持续集成
  • Sonar,代码质量管理
  • Git,版本管理

clipboard.png

三:分布式架构

高并发,高可用,海量数据,没有分布式的架构知识肯定是玩不转的:
  • 分布式架构原理
  • 分布式架构策略
  • 分布式中间件
  • 分布式架构实战

clipboard.png

四:微服务架构

业务越来越复杂,服务分层,微服务架构是架构升级的必由之路,Java技术体系,和微服务相关的技术有哪些呢?
  • 微服务框架
  • Spring Cloud
  • Docker与虚拟化
  • 微服务架构

clipboard.png

五:性能优化

任何脱离细节的ppt架构师都是耍流氓,向上能运筹帷幄,向下能解决一线性能问题,Java技术体系,需要了解:
  • 性能指标体系
  • JVM调优
  • Web调优
  • DB调优

clipboard.png

六:底层知识

从架构设计,到应用层调优,再深入了解底层原理,扎实的Java基本功才能让自己变为扫地神僧:
  • 内存模型
  • 并发模式
  • 线程模型
  • 锁细节

clipboard.png

如果大家想学习以上路线内容,在此我向大家推荐一个架构学习交流群。交流学习群号:478030634 里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构等这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多

文章有点长,大家觉得作者总结的还可以,大家可以点击下方二维码进行关注:《Java烂猪皮》公众号聊的不仅仅是Java技术知识,还有面试等干货,后期还有大量架构干货。大家一起关注吧!关注烂猪皮,你会了解的更多..............

文章属于原创:期间转发于
简书: https://www.jianshu.com/p/bc7...
掘金:https://juejin.im/post/5b44bc...
csdn:https://blog.csdn.net/yunzhaj...
头条:http://mp.toutiao.com/preview...
开源社区:https://my.oschina.net/u/3868...
《Java烂猪皮》公总号等平台

查看原文

薛定饿 收藏了文章 · 2018-07-16

【独家】终生受用的Redis高可用技术解决方案大全

最近很多朋友向我咨询关于高可用的方案的优缺点以及如何选择合适的方案线上使用,刚好最近在给宜人贷,光大银行做企业内训的时候也详细讲过,这里我再整理发出来,供大家参考,如有不妥之处,欢迎批评指正,也欢迎推荐更好的技术方案。不废话了,来看看方案吧~

总纲

图片描述

Redis常见的几种主要使用方式:

Redis 单副本

Redis 多副本(主从)

Redis Sentinel(哨兵)

Redis Cluster

Redis 自研

Redis各种使用方式的优缺点:

1、Redis单副本

clipboard.png

Redis 单副本,采用单个Redis节点部署架构,没有备用节点实时同步数据,不提供数据持久化和备份策略,适用于数据可靠性要求不高的纯缓存业务场景。

优点:

1、架构简单、部署方便

2、高性价比,当缓存使用时无需备用节点(单实例可用性可以用supervisor或crontab保证),当然为了满足业务的高可用性,也可以牺牲一个备用节点,但同时刻只有一个实例对外提供服务。

3、高性能

缺点:

1、不保证数据的可靠性

2、当缓存使用,进程重启后,数据丢失,即使有备用的节点解决高可用性,但是仍然不能解决缓存预热问题,因此不适用于数据可靠性要求高的业务。

3、高性能受限于单核CPU的处理能力(Redis是单线程机制),CPU为主要瓶颈,所以适合操作命令简单,排序、计算较少的场景。也可以考虑用memcached替代。

2、Redis多副本(主从)

clipboard.png

Redis 多副本,采用主从(replication)部署结构,相较于单副本而言最大的特点就是主从实例间数据实时同步,并且提供数据持久化和备份策略。主从实例部署在不同的物理服务器上,根据公司的基础环境配置,可以实现同时对外提供服务和读写分离策略。

优点:

1、高可靠性,一方面,采用双机主备架构,能够在主库出现故障时自动进行主备切换,从库提升为主库提供服务,保证服务平稳运行。另一方面,开启数据持久化功能和配置合理的备份策略,能有效的解决数据误操作和数据异常丢失的问题。

2、读写分离策略,从节点可以扩展主库节点的读能力,有效应对大并发量的读操作。

缺点:

1、故障恢复复杂,如果没有RedisHA系统(需要开发),当主库节点出现故障时,需要手动将一个从节点晋升为主节点,同时需要通知业务方变更配置,并且需要让其他从库节点去复制新主库节点,整个过程需要人为干预,比较繁琐。

2、主库的写能力受到单机的限制,可以考虑分片

3、主库的存储能力受到单机的限制,可以考虑Pika

4、原生复制的弊端在早期的版本也会比较突出,如:Redis复制中断后,Slave会发起psync,此时如果同步不成功,则会进行全量同步,主库执行全量备份的同时可能会造成毫秒或秒级的卡顿;又由于COW机制,导致极端情况下的主库内存溢出,程序异常退出或宕机;主库节点生成备份文件导致服务器磁盘IO和CPU(压缩)资源消耗;发送数GB大小的备份文件导致服务器出口带宽暴增,阻塞请求。建议升级到最新版本。

3、Redis Sentinel(哨兵)

clipboard.png

clipboard.png

Redis Sentinel是社区版本推出的原生高可用解决方案,Redis Sentinel部署架构主要包括两部分:Redis Sentinel集群和Redis数据集群,其中Redis Sentinel集群是由若干Sentinel节点组成的分布式集群。可以实现故障发现、故障自动转移、配置中心和客户端通知。Redis Sentinel的节点数量要满足2n+1(n>=1)的奇数个。

优点:

1、Redis Sentinel集群部署简单

2、能够解决Redis主从模式下的高可用切换问题

3、很方便实现Redis数据节点的线形扩展,轻松突破Redis自身单线程瓶颈,可极大满足对Redis大容量或高性能的业务需求。

4、可以实现一套Sentinel监控一组Redis数据节点或多组数据节点

缺点:

1、部署相对Redis 主从模式要复杂一些,原理理解更繁琐

2、资源浪费,Redis数据节点中slave节点作为备份节点不提供服务

3、Redis Sentinel主要是针对Redis数据节点中的主节点的高可用切换,对Redis的数据节点做失败判定分为主观下线和客观下线两种,对于Redis的从节点有对节点做主观下线操作,并不执行故障转移。

4、不能解决读写分离问题,实现起来相对复杂

建议:

1、如果监控同一业务,可以选择一套Sentinel集群监控多组Redis数据节点的方案,反之选择一套Sentinel监控一组Redis数据节点的方案

2、sentinel monitor <master-name> <ip> <port> <quorum> 配置中的<quorum>建议设置成Sentinel节点的一半加1,当Sentinel部署在多个IDC的时候,单个IDC部署的Sentinel数量不建议超过(Sentinel数量 – quorum)。

3、合理设置参数,防止误切,控制切换灵敏度控制

quorum

down-after-milliseconds 30000

failover-timeout 180000

maxclient

timeout

4、部署的各个节点服务器时间尽量要同步,否则日志的时序性会混乱

5、Redis建议使用pipeline和multi-keys操作,减少RTT次数,提高请求效率

6、自行搞定配置中心(zookeeper),方便客户端对实例的链接访问

4、Redis Cluster

clipboard.png

Redis Cluster是社区版推出的Redis分布式集群解决方案,主要解决Redis分布式方面的需求,比如,当遇到单机内存,并发和流量等瓶颈的时候,Redis Cluster能起到很好的负载均衡的目的。Redis Cluster集群节点最小配置6个节点以上(3主3从),其中主节点提供读写操作,从节点作为备用节点,不提供请求,只作为故障转移使用。Redis Cluster采用虚拟槽分区,所有的键根据哈希函数映射到0~16383个整数槽内,每个节点负责维护一部分槽以及槽所印映射的键值数据。

文章写到这里,也给大家送一个福利,给大家推荐一个Java架构方面的交流学习群:650385180,里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源。文章开头的总纲就是在群里面获取的,相信对于已经工作和遇到技术瓶颈的码友,在这个群里一定有你需要的内容。

优点:

1、无中心架构

2、数据按照slot存储分布在多个节点,节点间数据共享,可动态调整数据分布。

3、可扩展性,可线性扩展到1000多个节点,节点可动态添加或删除。

4、高可用性,部分节点不可用时,集群仍可用。通过增加Slave做standby数据副本,能够实现故障自动failover,节点之间通过gossip协议交换状态信息,用投票机制完成Slave到Master的角色提升。

5、降低运维成本,提高系统的扩展性和可用性。

缺点:

1、Client实现复杂,驱动要求实现Smart Client,缓存slots mapping信息并及时更新,提高了开发难度,客户端的不成熟影响业务的稳定性。目前仅JedisCluster相对成熟,异常处理部分还不完善,比如常见的“max redirect exception”。

2、节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout),被判断下线,这种failover是没有必要的。

3、数据通过异步复制,不保证数据的强一致性。

4、多个业务使用同一套集群时,无法根据统计区分冷热数据,资源隔离性较差,容易出现相互影响的情况。

5、Slave在集群中充当“冷备”,不能缓解读压力,当然可以通过SDK的合理设计来提高Slave资源的利用率。

6、key批量操作限制,如使用mset、mget目前只支持具有相同slot值的key执行批量操作。对于映射为不同slot值的key由于keys 不支持跨slot查询,所以执行mset、mget、sunion等操作支持不友好。

7、key事务操作支持有限,只支持多key在同一节点上的事务操作,当多个key分布于不同的节点上时无法使用事务功能。

8、key作为数据分区的最小粒度,因此不能将一个很大的键值对象如hash、list等映射到不同的节点。

9、不支持多数据库空间,单机下的redis可以支持到16个数据库,集群模式下只能使用1个数据库空间,即db 0。

10、复制结构只支持一层,从节点只能复制主节点,不支持嵌套树状复制结构。

11、避免产生hot-key,导致主库节点成为系统的短板。

12、避免产生big-key,导致网卡撑爆、慢查询等。

13、重试时间应该大于cluster-node-time时间

14、Redis Cluster不建议使用pipeline和multi-keys操作,减少max redirect产生的场景。

5、Redis自研 - 推荐推荐

clipboard.png

clipboard.png

Redis 自研的高可用解决方案,主要体现在配置中心、故障探测和failover的处理机制上,通常需要根据企业业务的实际线上环境来定制化。

优点:

1、高可靠性、高可用性

2、自主可控性高

3、贴切业务实际需求,可缩性好,兼容性好

缺点:

1、实现复杂,开发成本高

2、需要建立配套的周边设施,如监控,域名服务,存储元数据信息的数据库等。

3、维护成本高

查看原文

薛定饿 收藏了文章 · 2018-07-13

RESTful API 设计规范

RESTful API 设计规范

该仓库整理了目前比较流行的 RESTful api 设计规范,为了方便讨论规范带来的问题及争议,现把该文档托管于 Github,欢迎大家补充!!

Table of Contents

关于「能愿动词」的使用

为了避免歧义,文档大量使用了「能愿动词」,对应的解释如下:

  • 必须 (MUST):绝对,严格遵循,请照做,无条件遵守;
  • 一定不可 (MUST NOT):禁令,严令禁止;
  • 应该 (SHOULD) :强烈建议这样做,但是不强求;
  • 不该 (SHOULD NOT):强烈不建议这样做,但是不强求;
  • 可以 (MAY)可选 (OPTIONAL) :选择性高一点,在这个文档内,此词语使用较少;
参见:RFC 2119

Protocol

客户端在通过 API 与后端服务通信的过程中,应该 使用 HTTPS 协议。

API Root URL

API 的根入口点应尽可能保持足够简单,这里有两个常见的 URL 根例子:

  • api.example.com/*
  • example.com/api/*
如果你的应用很庞大或者你预计它将会变的很庞大,那 应该API 放到子域下(api.example.com)。这种做法可以保持某些规模化上的灵活性。

Versioning

所有的 API 必须保持向后兼容,你 必须 在引入新版本 API 的同时确保旧版本 API 仍然可用。所以 应该 为其提供版本支持。

目前比较常见的两种版本号形式:

在 URL 中嵌入版本编号

api.example.com/v1/*

这种做法是版本号直观、易于调试;另一种做法是,将版本号放在 HTTP Header 头中:

通过媒体类型来指定版本信息

Accept: application/vnd.example.com.v1+json

其中 vnd 表示 Standards Tree 标准树类型,有三个不同的树: xprsvnd。你使用的标准树需要取决于你开发的项目

  • 未注册的树(x)主要表示本地和私有环境
  • 私有树(prs)主要表示没有商业发布的项目
  • 供应商树(vnd)主要表示公开发布的项目
后面几个参数依次为应用名称(一般为应用域名)、版本号、期望的返回格式。

至于具体把版本号放在什么地方,这个问题一直存在很大的争议,但由于我们大多数时间都在使用 Laravel 开发,应该 使用 dingo/api 来快速构建应用,它采用第二种方式来管理 API 版本,并且已集成了标准的 HTTP Response

Endpoints

端点就是指向特定资源或资源集合的 URL。在端点的设计中,你 必须 遵守下列约定:

  • URL 的命名 必须 全部小写
  • URL 中资源(resource)的命名 必须 是名词,并且 必须 是复数形式
  • 必须 优先使用 Restful 类型的 URL
  • URL 必须 是易读的
  • URL 一定不可 暴露服务器架构
至于 URL 是否必须使用连字符(-) 或下划线(_),不做硬性规定,但 必须 根据团队情况统一一种风格。

来看一个反例

再来看一个正列

HTTP 动词

对于资源的具体操作类型,由 HTTP 动词表示。常用的 HTTP 动词有下面五个(括号里是对应的 SQL 命令)。

  • GET(SELECT):从服务器取出资源(一项或多项)。
  • POST(CREATE):在服务器新建一个资源。
  • PUT(UPDATE):在服务器更新资源(客户端提供改变后的完整资源)。
  • PATCH(UPDATE):在服务器更新资源(客户端提供改变的属性)。
  • DELETE(DELETE):从服务器删除资源。

其中

1 删除资源 必须DELETE 方法
2 创建新的资源 必须 使用 POST 方法
3 更新资源 应该 使用 PUT 方法
4 获取资源信息 必须 使用 GET 方法

针对每一个端点来说,下面列出所有可行的 HTTP 动词和端点的组合

请求方法URL描述
GET/zoos列出所有的动物园(ID和名称,不要太详细)
POST/zoos新增一个新的动物园
GET/zoos/{zoo}获取指定动物园详情
PUT/zoos/{zoo}更新指定动物园(整个对象)
PATCH/zoos/{zoo}更新动物园(部分对象)
DELETE/zoos/{zoo}删除指定动物园
GET/zoos/{zoo}/animals检索指定动物园下的动物列表(ID和名称,不要太详细)
GET/animals列出所有动物(ID和名称)。
POST/animals新增新的动物
GET/animals/{animal}获取指定的动物详情
PUT/animals/{animal}更新指定的动物(整个对象)
PATCH/animals/{animal}更新指定的动物(部分对象)
GET/animal_types获取所有动物类型(ID和名称,不要太详细)
GET/animal_types/{type}获取指定的动物类型详情
GET/employees检索整个雇员列表
GET/employees/{employee}检索指定特定的员工
GET/zoos/{zoo}/employees检索在这个动物园工作的雇员的名单(身份证和姓名)
POST/employees新增指定新员工
POST/zoos/{zoo}/employees在特定的动物园雇佣一名员工
DELETE/zoos/{zoo}/employees/{employee}从某个动物园解雇一名员工
超出 Restful 端点的,应该 模仿上表的方式来定义端点。

Filtering

如果记录数量很多,服务器不可能都将它们返回给用户。API 应该 提供参数,过滤返回结果。下面是一些常见的参数。
  • ?limit=10:指定返回记录的数量
  • ?offset=10:指定返回记录的开始位置。
  • ?page=2&per_page=100:指定第几页,以及每页的记录数。
  • ?sortby=name&order=asc:指定返回结果按照哪个属性排序,以及排序顺序。
  • ?animal_type_id=1:指定筛选条件

所有 URL 参数 必须 是全小写,必须 使用下划线类型的参数形式。

分页参数 必须 固定为 pageper_page

经常使用的、复杂的查询 应该 标签化,降低维护成本。如

GET /trades?status=closed&sort=sortby=name&order=asc

# 可为其定制快捷方式
GET /trades/recently_closed

Authentication

应该 使用 OAuth2.0 的方式为 API 调用者提供登录认证。必须 先通过登录接口获取 Access Token 后再通过该 token 调用需要身份认证的 API

Oauth 的端点设计示列

  • RFC 6749 /token
  • Twitter /oauth2/token
  • Fackbook /oauth/access_token
  • Google /o/oauth2/token
  • Github /login/oauth/access_token
  • Instagram /oauth/authorize

客户端在获得 access token 的同时 必须 在响应中包含一个名为 expires_in 的数据,它表示当前获得的 token 会在多少 后失效。

{
    "access_token": "token....",
    "token_type": "Bearer",
    "expires_in": 3600
}

客户端在请求需要认证的 API 时,必须 在请求头 Authorization 中带上 access_token

Authorization: Bearer token...

当超过指定的秒数后,access token 就会过期,再次用过期/或无效的 token 访问时,服务端 应该 返回 invalid_token 的错误或 401 错误码。

HTTP/1.1 401 Unauthorized
Content-Type: application/json
Cache-Control: no-store
Pragma: no-cache

{
    "error": "invalid_token"
}
Laravel 开发中,应该 使用 JWT 来为管理你的 Token,并且 一定不可api 中间件中开启请求 session

Response

所有的 API 响应,必须 遵守 HTTP 设计规范,必须 选择合适的 HTTP 状态码。一定不可 所有接口都返回状态码为 200HTTP 响应,如:

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com

{
    "code": 0,
    "msg": "success",
    "data": {
        "username": "username"
    }
}

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com

{
    "code": -1,
    "msg": "该活动不存在",
}

下表列举了常见的 HTTP 状态码

状态码描述
1xx代表请求已被接受,需要继续处理
2xx请求已成功,请求所希望的响应头或数据体将随此响应返回
3xx重定向
4xx客户端原因引起的错误
5xx服务端原因引起的错误
只有来自客户端的请求被正确的处理后才能返回 2xx 的响应,所以当 API 返回 2xx 类型的状态码时,前端 必须 认定该请求已处理成功。

必须强调的是,所有 API一定不可 返回 1xx 类型的状态码。当 API 发生错误时,必须 返回出错时的详细信息。目前常见返回错误信息的方法有两种:

1、将错误详细放入 HTTP 响应首部;

X-MYNAME-ERROR-CODE: 4001
X-MYNAME-ERROR-MESSAGE: Bad authentication token
X-MYNAME-ERROR-INFO: http://docs.example.com/api/v1/authentication

2、直接放入响应实体中;

HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:02:59 GMT
Connection: keep-alive

{"error_code":40100,"message":"Unauthorized"}

考虑到易读性和客户端的易处理性,我们 必须 把错误信息直接放到响应实体中,并且错误格式 应该 满足如下格式:

{
    "message": "您查找的资源不存在",
    "error_code": 404001
}

其中错误码(error_code必须HTTP 状态码对应,也方便错误码归类,如:

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:15:52 GMT
Connection: keep-alive

{"error_code":429001,"message":"你操作太频繁了"}
HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:19:27 GMT
Connection: keep-alive

{"error_code":403002,"message":"用户已禁用"}

应该 在返回的错误信息中,同时包含面向开发者和面向用户的提示信息,前者可方便开发人员调试,后者可直接展示给终端用户查看如:

{
    "message": "直接展示给终端用户的错误信息",
    "error_code": "业务错误码",
    "error": "供开发者查看的错误信息",
    "debug": [
        "错误堆栈,必须开启 debug 才存在"
    ]
}

下面详细列举了各种情况 API 的返回说明。

200 ok

200 状态码是最常见的 HTTP 状态码,在所有 成功GET 请求中,必须 返回此状态码。HTTP 响应实体部分 必须 直接就是数据,不要做多余的包装。

错误示例:

HTTP/1.1 200 ok
Content-Type: application/json
Server: example.com

{
    "user": {
        "id":1,
        "nickname":"fwest",
        "username": "example"
    }
}

正确示例:

1、获取单个资源详情

{
    "id": 1,
    "username": "godruoyi",
    "age": 88,
}

2、获取资源集合

[
    {
        "id": 1,
        "username": "godruoyi",
        "age": 88,
    },
    {
        "id": 2,
        "username": "foo",
        "age": 88,
    }
]

3、额外的媒体信息

{
    "data": [
        {
            "id": 1,
            "avatar": "https://lorempixel.com/640/480/?32556",
            "nickname": "fwest",
            "last_logined_time": "2018-05-29 04:56:43",
            "has_registed": true
        },
        {
            "id": 2,
            "avatar": "https://lorempixel.com/640/480/?86144",
            "nickname": "zschowalter",
            "last_logined_time": "2018-06-16 15:18:34",
            "has_registed": true
        }
    ],
    "meta": {
        "pagination": {
            "total": 101,
            "count": 2,
            "per_page": 2,
            "current_page": 1,
            "total_pages": 51,
            "links": {
                "next": "http://api.example.com?page=2"
            }
        }
    }
}
其中,分页和其他额外的媒体信息,必须放到 meta 字段中。

201 Created

当服务器创建数据成功时,应该 返回此状态码。常见的应用场景是使用 POST 提交用户信息,如:

  • 添加了新用户
  • 上传了图片
  • 创建了新活动

等,都可以返回 201 状态码。需要注意的是,你可以选择在用户创建成功后返回新用户的数据

HTTP/1.1 201 Created
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:13:40 GMT
Connection: keep-alive

{
    "id": 1,
    "avatar": "https:\/\/lorempixel.com\/640\/480\/?32556",
    "nickname": "fwest",
    "last_logined_time": "2018-05-29 04:56:43",
    "created_at": "2018-06-16 17:55:55",
    "updated_at": "2018-06-16 17:55:55"
}

也可以返回一个响应实体为空的 HTTP Response 如:

HTTP/1.1 201 Created
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:12:20 GMT
Connection: keep-alive
这里我们 应该 采用第二种方式,因为大多数情况下,客户端只需要知道该请求操作成功与否,并不需要返回新资源的信息。

202 Accepted

该状态码表示服务器已经接受到了来自客户端的请求,但还未开始处理。常用短信发送、邮件通知、模板消息推送等这类很耗时需要队列支持的场景中;

返回该状态码时,响应实体 必须 为空。
HTTP/1.1 202 Accepted
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:25:15 GMT
Connection: keep-alive

204 No Content

该状态码表示响应实体不包含任何数据,其中:

  • 在使用 DELETE 方法删除资源 成功 时,必须 返回该状态码
  • 使用 PUTPATCH 方法更新数据 成功 时,也 应该 返回此状态码
HTTP/1.1 204 No Content
Server: nginx/1.11.9
Date: Sun, 24 Jun 2018 09:29:12 GMT
Connection: keep-alive

3xx 重定向

所有 API不该 返回 3xx 类型的状态码。因为 3xx 类型的响应格式一般为下列格式:

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 09:41:50 GMT
Location: https://example.com
Connection: keep-alive

<!DOCTYPE html>
<html>
    <head>
        <meta charset="UTF-8" />
        <meta http-equiv="refresh" content="0;url=https://example.com" />

        <title>Redirecting to https://example.com</title>
    </head>
    <body>
        Redirecting to <a href="https://example.com">https://example.com</a>.
    </body>
</html>

所有 API一定不可 返回纯 HTML 结构的响应;若一定要使用重定向功能,可以 返回一个响应实体为空的 3xx 响应,并在响应头中加上 Location 字段:

HTTP/1.1 302 Found
Server: nginx/1.11.9
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Date: Sun, 24 Jun 2018 09:52:50 GMT
Location: https://godruoyi.com
Connection: keep-alive

400 Bad Request

由于明显的客户端错误(例如,请求语法格式错误、无效的请求、无效的签名等),服务器 应该 放弃该请求。

当服务器无法从其他 4xx 类型的状态码中找出合适的来表示错误类型时,都 必须 返回该状态码。
HTTP/1.1 400 Bad Request
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:22:36 GMT
Connection: keep-alive

{"error_code":40000,"message":"无效的签名"}

401 Unauthorized

该状态码表示当前请求需要身份认证,以下情况都 必须 返回该状态码。

  • 未认证用户访问需要认证的 API
  • access_token 无效/过期
客户端在收到 401 响应后,都 应该 提示用户进行下一步的登录操作。
HTTP/1.1 401 Unauthorized
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
WWW-Authenticate: JWTAuth
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:17:02 GMT
Connection: keep-alive

{"message":"Token Signature could not be verified.","error_code": "40100"}

403 Forbidden

该状态码可以简单的理解为没有权限访问该请求,服务器收到请求但拒绝提供服务。

如当普通用户请求操作管理员用户时,必须 返回该状态码。

HTTP/1.1 403 Forbidden
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 13:05:34 GMT
Connection: keep-alive

{"error_code":40301,"message":"权限不足"}

404 Not Found

该状态码表示用户请求的资源不存在,如

  • 获取不存在的用户信息 (get /users/9999999)
  • 访问不存在的端点

必须 返回该状态码,若该资源已永久不存在,则 应该 返回 410 响应。

405 Method Not Allowed

当客户端使用的 HTTP 请求方法不被服务器允许时,必须 返回该状态码。

如客户端调用了 POST 方法来访问只支持 GET 方法的 API

该响应 必须 返回一个 Allow 头信息用以表示出当前资源能够接受的请求方法的列表。

HTTP/1.1 405 Method Not Allowed
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Allow: GET, HEAD
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:30:57 GMT
Connection: keep-alive

{"message":"405 Method Not Allowed","error_code": 40500}

406 Not Acceptable

API 在不支持客户端指定的数据格式时,应该返回此状态码。如支持 JSONXML 输出的 API 被指定返回 YAML 格式的数据时。

Http 协议一般通过请求首部的 Accept 来指定数据格式

408 Request Timeout

客户端请求超时时 必须 返回该状态码,需要注意的时,该状态码表示 客户端请求超时,在涉及第三方 API 调用超时时,一定不可 返回该状态码。

409 Confilct

该状态码表示因为请求存在冲突无法处理。如通过手机号码提供注册功能的 API,当用户提交的手机号已存在时,必须 返回此状态码。

HTTP/1.1 409 Conflict
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:19:04 GMT
Connection: keep-alive

{"error_code":40900,"message":"手机号已存在"}

410 Gone

404 类似,该状态码也表示请求的资源不存在,只是 410 状态码进一步表示所请求的资源已不存在,并且未来也不会存在。在收到 410 状态码后,客户端 应该 停止再次请求该资源。

413 Request Entity Too Large

该状态码表示服务器拒绝处理当前请求,因为该请求提交的实体数据大小超过了服务器愿意或者能够处理的范围。

此种情况下,服务器可以关闭连接以免客户端继续发送此请求。

如果这个状况是临时的,服务器 应该 返回一个 Retry-After 的响应头,以告知客户端可以在多少时间以后重新尝试。

414 Request-URI Too Long

该状态码表示请求的 URI 长度超过了服务器能够解释的长度,因此服务器拒绝对该请求提供服务。

415 Unsupported Media Type

通常表示服务器不支持客户端请求首部 Content-Type 指定的数据格式。如在只接受 JSON 格式的 API 中放入 XML 类型的数据并向服务器发送,都 应该 返回该状态码。

该状态码也可用于如:只允许上传图片格式的文件,但是客户端提交媒体文件非法或不是图片类型,这时 应该 返回该状态码:

HTTP/1.1 415 Unsupported Media Type
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 12:09:40 GMT
Connection: keep-alive

{"error_code":41500,"message":"不允许上传的图片格式"}

429 Too Many Requests

该状态码表示用户请求次数超过允许范围。如 API 设定为 60次/分钟,当用户在一分钟内请求次数超过 60 次后,都 应该 返回该状态码。并且也 应该 在响应首部中加上下列头部:

X-RateLimit-Limit: 10 请求速率(由应用设定,其单位一般为小时/分钟等,这里是 10次/5分钟)
X-RateLimit-Remaining: 0 当前剩余的请求数量
X-RateLimit-Reset: 1529839462 重置时间
Retry-After: 120 下一次访问应该等待的时间(秒)

列子

HTTP/1.1 429 Too Many Requests
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
X-RateLimit-Limit: 10
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1529839462
Retry-After: 290
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 11:19:32 GMT
Connection: keep-alive

{"message":"You have exceeded your rate limit.","error_code":42900}

必须 为所有的 API 设置 Rate Limit 支持。

500 Internal Server Error

该状态码 必须 在服务器出错时抛出,对于所有的 500 错误,都 应该 提供完整的错误信息支持,也方便跟踪调试。

503 Service Unavailable

该状态码表示服务器暂时处理不可用状态,当服务器需要维护或第三方 API 请求超时/不可达时,都 应该 返回该状态码,其中若是主动关闭 API 服务,应该 在返回的响应首部加上 Retry-After 头部,表示多少秒后可以再次访问。

HTTP/1.1 503 Service Unavailable
Server: nginx/1.11.9
Content-Type: application/json
Transfer-Encoding: chunked
Cache-Control: no-cache, private
Date: Sun, 24 Jun 2018 10:56:20 GMT
Retry-After: 60
Connection: keep-alive

{"error_code":50300,"message":"服务维护中"}

其他 HTTP 状态码请参考 HTTP 状态码- 维基百科

版权声明

版权声明:自由转载-非商用-非衍生-保持署名(创意共享3.0许可证

建议参考

restful-api-design-references

Principles of good RESTful API Design(译)

理解 RESTful 架构

RESTful API 设计指南

HTTP 状态码- 维基百科

LICENSE

MIT License

Copyright (c) 2018 godruoyi

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

查看原文

认证与成就

  • 获得 12 次点赞
  • 获得 4 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 4 枚铜徽章

擅长技能
编辑

开源项目 & 著作
编辑

注册于 2017-09-04
个人主页被 773 人浏览