arunfung

arunfung 查看完整档案

上海编辑金华职业技术学院  |  计算机应用 编辑上海慧贤网络科技有限公司  |  项目负责人 主程 编辑 arunfung.com 编辑
编辑

努力做最好的自己

个人动态

arunfung 关注了用户 · 9月18日

Doto丶 @doto_5cf7722c57196

不知名后端工程师,喜欢code,喜欢学习,喜欢记录.

个人公众号[呼延十], 博客地址:http://huyan.couplecoders.tech/

关注 2

arunfung 关注了专栏 · 7月1日

Corwien

为者常成,行者常至!

关注 959

arunfung 收藏了文章 · 6月29日

PHP程序员如何转Java开发?

作为一名有四年开发经验的PHP程序员,对Java强大的生态无比艳羡,尤其在开发一些比较大型的项目时,Java强大成熟的生态可以帮助我们快速完成开发,这是PHP比不了的,而且,最最重要的一点是,Java的薪资普遍比PHP的要高一大截,大厂对高级Java的需求量很大,所以,为了牛奶和面包,我们程序员不要自我设限,多学一门语言,多条路。

从哪里开始?

相信很多准备学习java的同学们一开始都抱着极大的热情,开始买各种java入门书,网上找各种入门的资料,可是对于新手而言,光搞Java的开发环境和IDE配置就很容易晕,更重要的是学习了Java 的基础知识后,不知道后边该学什么,顺序是什么,该学那些框架,有些框架现在已经淘汰不用了,比如 Hibernate,Struts,所以,有一个全面、完整的学习规划是很重要的。

学习路线

最好的学习方法就是由一个完整的实战项目驱动,哪个知识点不会,就补哪个,这样不至于学了很多理论上的东西而产生迷惘。比如我的目标是学习Java web开发,能够搞一个电商网站,目前最流行的就是 SSM 框架,那么,我都要学习那些知识呢?

按顺序学习清单:
1 .JAVA 基础 --- HelloWorld
2 .JAVA 基础 --- 面向对象
3 .JAVA 基础 --- 变量
4 .JAVA 基础 --- 操作符
5 .JAVA 基础 --- 控制流程
6 .JAVA 基础 --- 数组
7 .JAVA 基础 --- 类和对象
8 .JAVA 基础 --- 接口与继承
9 .JAVA 基础 --- 数字与字符串
10 .JAVA 基础 --- 日期
11 .JAVA 中级 --- 异常处理
12 .JAVA 中级 --- I/O
13 .JAVA 中级 --- 集合框架
14 .JAVA 中级 --- 泛型
15 .JAVA 中级 --- JDBC
16 .前端部分 --- HTML
17 .前端部分 --- CSS
18 .前端部分 --- JavaScript
19 .前端部分 --- JSON
20 .前端部分 --- Ajax
21 .前端部分 --- JQuery
22 .前端部分 --- BootStrap
23 .J2EE --- Tomcat
24 .J2EE --- Servlet
25 .J2EE --- HTTP协议
26 .J2EE --- JSP
27 .J2EE --- MVC
28 .J2EE --- Filter
29 .J2EE --- Listener
30 .JAVA 框架 --- Spring
31 .JAVA 框架 --- Spring MVC
32 .JAVA 框架 --- Mybatis
33 .JAVA 框架 --- Spring+Mybatis
34 .JAVA 框架 --- SSM
35 .工具和中间件 --- Git
36 .工具和中间件 --- Intellij IDEA
37 .工具和中间件 --- 部署到Linux
38 .实践项目 --- 天猫整站SSM

完整的路线图:

2DxxmyfpPR.png

注:上图截取于how2j.cn Java学习网站

怎么学习?

在学习之前,我们要对一些基本的概念做一些了解,否则在学习时很容易懵逼。

基础概念

JavaSE: 即J2SE, java标准版, 主要做一般的java应用, 比如, 应用软件/ QQ之类的通信软件等等。
JavaEE: 即J2EE, 主要做企业应用, 比如公司网站, 企业解决方案等。
JavaME: 即J2ME, 主要面向嵌入式等设备应用的开发, 比如手机游戏等。

Javase基础

Javase作为Java的基础尤为的重要,以后你的框架是否可以学懂,完全要看对于Javase的理解,有很多人做了一两年的Java开发,但是对于Javase的理解还是远远不够的,所以一个学习Java的新手,Javase将会成为你的起点。

JavaSE其中重点涵盖了环境搭建、基础语法、面向对象核心、异常、数组、常用类、集合、线程、IO流、反射机制、网络编程。

JavaEE基础

J2ee 基础包括 Servlet,JSP,Filter,Listener 等相关知识。

JavaEE框架
企业级开发,Struts2、Spring框架、Hibernate框架、Maven核心技术、MyBaits框架、SpringMVC、SpringBoot等。

image.png

image.png

注:上图截取于how2j.cn Java学习网站

开发工具

在刚开始学习之时,我们可以使用 Eclipse 进行开发,锻炼我们快速熟悉代码的能力,等学习一段时间之后可以使用IDEA进行开发。

拳不离手曲不离口,最重要的是要敲代码,这样才能将学习的内容消化。

学习资源

过年受疫情影响在家呆的这段时间,发现了一个非常好的Java学习网站,个人极力推荐,我就是看着这个网站学习完整Javaweb 的内容的。学Java,只看这个网站https://how2j.cn 就可以出师了,不用再到其他地方折腾了,站长已经为我们整理了整个路线图,并且有视频讲解和源代码下载,还有更详细的博文说明一步一步引导我们学习,整合的非常完善。

最强Java学习网站推荐:https://how2j.cn?p=126405

image.png

注:上图截取于how2j.cn Java学习网站

小结

骚年,作为2020年的年轻人,要有危机感,不能总吃老本,要多学习一些东西,多掌握一门工具,丰富自己,这样才不会被淘汰。

查看原文

arunfung 收藏了文章 · 5月17日

面试:原来Redis常用的五种数据类型底层结构是这样的

关注我,可以获取最新知识、经典面试题以及微服务技术分享

  在Redis中会涉及很多数据结构,比如SDS,双向链表、字典、压缩列表、整数集合等等。Redis会基于这些数据结构自定义一个对象系统,而且自定义的对象系统有很多好处。

通过对以下的Redis对象系统的学习,可以了解Redis设计原理以及初衷,为了我们在使用Redis的时候,更加能够理解到其原理和定位问题。

Redis 对象

Redis基于上述的数据结构自定义一个Object 系统,Object结构:

redisObject结构:
     typedef struct redisObject{
    //类型
    unsigned type:4;
    //编码
    unsigned encoding:4;
    //指向底层实现数据结构的指针
    void *ptr;
    ….. 
} 

Object 系统包含五种Object:

  • String:字符串对象
  • List:列表对象
  • Hash:哈希对象
  • Set:集合对象
  • ZSet:有序集合

Redis使用对象来表示数据库中的键和值,即每新建一个键值对,至少创建有两个对象,而且使用对象的具有以下好处:

1. redis可以在执行命令前会根据对象的类型判断一个对象是否可以执行给定的命令
2. 针对不同的使用场景,为对象设置不同的数据结构实现,从而优化对象的不同场景夏的使用效率
3. 对象系统还可以基于引用计数计数的内存回收机制,自动释放对象所占用的内存,或者还可以让多个数据库键共享同一个对象来节约内存。
4. redis对象带有访问时间记录信息,使用该信息可以进行优化空转时长较大的key,进行删除!



对象的ptr指针指向对象的底层现实数据结构,而这些数据结构由对象的encoding属性决定,对应关系:

编码常量编码对应的底层数据结构
REDIS_ENCODING_INTlong类型的整数
REDIS_ENCODING_EMBSTRembstr编码的简单动态字符串
REDIS_ENCODING_RAW简单动态字符串
REDIS_ENCODING_HT字典
REDIS_ENCODING_LINKEDLIST双向链表
REDIS_ENCODING_ZIPLIST压缩列表
REDIS_ENCODING_INTSET整数集合
REDIS_ENCODING_SKIPLIST跳跃表和字典



每种Object对象至少有两种不同的编码,对应关系:

类型编码对象
Stringint整数值实现
Stringembstrsds实现 <=39 字节
Stringrawsds实现 > 39字节
Listziplist压缩列表实现
Listlinkedlist双端链表实现
Setintset整数集合使用
Sethashtable字典实现
Hashziplist压缩列表实现
Hashhashtable字典使用
Sorted setziplist压缩列表实现
Sorted setskiplist跳跃表和字典


String 对象

字符串对象编码可以int 、raw或者embstr,如果保存的值为整数值且这个值可以用long类型表示,使用int编码,其他编码类似。

比如:int编码的String Object

redis> set number 520 
 ok
 redis> OBJECT ENCODING number 
"int"

String Object结构:

file

### String 对象之间的编码转换
int编码的字符串对象和embstr编码的字符串对象在条件满足的情况下,会被转换为raw编码的字符串对象。

比如:对int编码的字符串对象进行append命令时,就会使得原来是int变为raw编码字符串


List对象

list对象可以为ziplist或者为linkedlist,对应底层实现ziplist为压缩列表,linkedlist为双向列表。

Redis>RPUSH numbers “Ccww” 520 1

用ziplist编码的List对象结构:
file

用linkedlist编码的List对象结构:

file

List对象的编码转换:

当list对象可以同时满足以下两个条件时,list对象使用的是ziplist编码:

1. list对象保存的所有字符串元素的长度都小于64字节
2. list对象保存的元素数量小于512个,

不能满足这两个条件的list对象需要使用linkedlist编码。

Hash对象

Hash对象的编码可以是ziplist或者hashtable
其中,ziplist底层使用压缩列表实现:

  • 保存同一键值对的两个节点紧靠相邻,键key在前,值vaule在后
  • 先保存的键值对在压缩列表的表头方向,后来在表尾方向

hashtable底层使用字典实现,Hash对象种的每个键值对都使用一个字典键值对保存:

  • 字典的键为字符串对象,保存键key
  • 字典的值也为字符串对象,保存键值对的值

比如:HSET命令

redis>HSET author name  "Ccww"
(integer)

redis>HSET author age  18
(integer)

redis>HSET author sex  "male"
(integer)

ziplist的底层结构:

file

hashtable底层结构:

file

Hash对象的编码转换:

当list对象可以同时满足以下两个条件时,list对象使用的是ziplist编码:

1. list对象保存的所有字符串元素的长度都小于64字节
2. list对象保存的元素数量小于512个,

不能满足这两个条件的hash对象需要使用hashtable编码

Note:这两个条件的上限值是可以修改的,可查看配置文件hash-max-zaiplist-value和hash-max-ziplist-entries


Set对象:

Set对象的编码可以为intset或者hashtable

  • intset编码:使用整数集合作为底层实现,set对象包含的所有元素都被保存在intset整数集合里面
  • hashtable编码:使用字典作为底层实现,字典键key包含一个set元素,而字典的值则都为null

inset编码Set对象结构:

    redis> SAD number  1 3 5 
    

file

hashtable编码Set对象结构:

redis> SAD Dfruits  “apple”  "banana" " cherry"

file

Set对象的编码转换:

使用intset编码:

1. set对象保存的所有元素都是整数值
2. set对象保存的元素数量不超过512个

不能满足这两个条件的Set对象使用hashtable编码

ZSet对象

ZSet对象的编码 可以为ziplist或者skiplist
ziplist编码,每个集合元素使用相邻的两个压缩列表节点保存,一个保存元素成员,一个保存元素的分值,然后根据分数进行从小到大排序。

ziplist编码的ZSet对象结构:

Redis>ZADD price 8.5 apple 5.0 banana 6.0 cherry

file

skiplist编码的ZSet对象使用了zset结构,包含一个字典和一个跳跃表

Type struct zset{

    Zskiplist *zsl;
    dict *dict;
    ...
}

skiplist编码的ZSet对象结构

file

ZSet对象的编码转换

当ZSet对象同时满足以下两个条件时,对象使用ziplist编码

1. 有序集合保存的元素数量小于128个
2. 有序集合保存的所有元素的长度都小于64字节

不能满足以上两个条件的有序集合对象将使用skiplist编码。

Note:可以通过配置文件中zset-max-ziplist-entries和zset-max-ziplist-vaule

查看原文

arunfung 收藏了文章 · 5月11日

系统的讲解 - SSO单点登录

概念

SSO 英文全称 Single Sign On,单点登录。

在多个应用系统中,只需要登录一次,就可以访问其他相互信任的应用系统。

比如:淘宝网(www.taobao.com),天猫网(www.tmall.com),聚划算(ju.taobao.com),飞猪网(www.fliggy.com)等,这些都是阿里巴巴集团的网站。在这些网站中,我们在其中一个网站登录了,再访问其他的网站时,就无需再进行登录,这就是 SSO 的主要用途。

好处

用户角度

用户能够做到一次登录多次使用,无需记录多套用户名和密码,省心。

系统管理员角度

管理员只需维护好一个统一的账号中心就可以了,方便。

新系统开发角度

新系统开发时只需直接对接统一的账号中心即可,简化开发流程,省时。

技术实现

流程图

clipboard.png

流程介绍

如果没这个介绍,看上图肯定是懵懵的。

系统A和系统B都是前后端分离的,比如前端框架用的 React / Vue / Angular,都是通过 NPM 编译后独立部署的,前后端完全通过HTTP接口的方式进行交互,也有可能前后端项目的域名都不一样。

SSO认证中心不是前后端分离的,就是前端代码和后端代码部署在一个项目中。

为什么用这两种情况呢?

其实就是为了,在流程图上出现这两种情况,这样的清楚了,后期改成任何一种就都清楚了。

试想一下:

三个系统都是前后端分离的情况,流程图应该怎么调整?

三个系统都不是前后端分离的情况,流程图应该怎么调整?

对外接口

系统A和系统B:用户退出接口。

SSO 认证中心:用户退出接口和token验证接口。

登录

如上述流程图一致。

系统A和系统B:使用token认证登录。

SSO 认证中心:使用会话认证登录。

前后端分离项目,登录使用token进行解决,前端每次请求接口时都必须传递token参数。

退出

clipboard.png

上图,表示的是从某一个系统退出的流程图。

退出,还可以从SSO认证中心退出,然后调取各个系统的用户退出接口。

当用户再进行操作的时候,就会跳转到SSO的登录界面。

Token 生成方式

创建全局会话可以使用session,将session存储到redis中。

令牌的生成可以使用JWT。

PHP JWT参考地址:https://github.com/lcobucci/jwt

当然还可以自定义token的生成方式。

小结

讲解了什么是SSO,以及SSO的用途与好处,同时根据流程图一步步进行梳理,基本上就可以实现了。

期间遇到任何问题,都可以关注公众号和我进行交流。

扩展

SSO与OAuth的区别

谈到SSO很多人就想到OAuth,也有谈到OAuth想到SSO的,在这里我简单的说一下区别。

通俗的解释,SSO是处理一个公司内的不同应用系统之间的登录问题,比如阿里巴巴旗下有很多应用系统,我们只需要登录一个系统就可以实现不同系统之间的跳转。

OAuth是不同公司遵循的一种授权方案,也是一种授权协议,通常都是由大公司提供,比如腾讯,微博。我们常用的QQ登录,微博登录等,使用OAuth的好处是可以使用其他第三方账号进行登录系统,减少了因用户懒,不愿注册而导致用户流失的风险。

现在一些支付业务也用OAuth,比如微信支付,支付宝支付。

还有一些开放平台也用OAuth,比如百度开放平台,腾讯开放平台。

SSO与RBAC的关系

如果企业有多个管理系统,现由原来的每个系统都有一个登录,调整为统一登录认证。

那么每个管理系统都有权限控制,吸取统一登录认证的经验,我们也可以做一套统一的RBAC权限认证。

推荐阅读

一起学习

查看原文

arunfung 收藏了文章 · 5月11日

MySQL/InnoDB中,乐观锁、悲观锁、共享锁、排它锁、行锁、表锁、死锁概念的理解

MySQL/InnoDB的加锁,一直是一个面试中常问的话题。例如,数据库如果有高并发请求,如何保证数据完整性?产生死锁问题如何排查并解决?我在工作过程中,也会经常用到,乐观锁,排它锁,等。于是今天就对这几个概念进行学习,屡屡思路,记录一下。

注:MySQL是一个支持插件式存储引擎的数据库系统。本文下面的所有介绍,都是基于InnoDB存储引擎,其他引擎的表现,会有较大的区别。

存储引擎查看

MySQL给开发者提供了查询存储引擎的功能,我这里使用的是MySQL5.6.4,可以使用:

SHOW ENGINES

乐观锁

用数据版本(Version)记录机制实现,这是乐观锁最常用的一种实现方式。何谓数据版本?即为数据增加一个版本标识,一般是通过为数据库表增加一个数字类型的 “version” 字段来实现。当读取数据时,将version字段的值一同读出,数据每更新一次,对此version值加1。当我们提交更新的时候,判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对,如果数据库表当前版本号与第一次取出来的version值相等,则予以更新,否则认为是过期数据。

举例

1、数据库表设计

三个字段,分别是id,value、version

select id,value,version from TABLE where id=#{id}

2、每次更新表中的value字段时,为了防止发生冲突,需要这样操作

update TABLE
set value=2,version=version+1
where id=#{id} and version=#{version};

悲观锁

与乐观锁相对应的就是悲观锁了。悲观锁就是在操作数据时,认为此操作会出现数据冲突,所以在进行每次操作时都要通过获取锁才能进行对相同数据的操作,这点跟java中的synchronized很相似,所以悲观锁需要耗费较多的时间。另外与乐观锁相对应的,悲观锁是由数据库自己实现了的,要用的时候,我们直接调用数据库的相关语句就可以了。

说到这里,由悲观锁涉及到的另外两个锁概念就出来了,它们就是共享锁与排它锁。共享锁和排它锁是悲观锁的不同的实现,它俩都属于悲观锁的范畴。

使用,排它锁 举例

要使用悲观锁,我们必须关闭mysql数据库的自动提交属性,因为MySQL默认使用autocommit模式,也就是说,当你执行一个更新操作后,MySQL会立刻将结果进行提交。

我们可以使用命令设置MySQL为非autocommit模式:

set autocommit=0;

# 设置完autocommit后,我们就可以执行我们的正常业务了。具体如下:

# 1. 开始事务

begin;/begin work;/start transaction; (三者选一就可以)

# 2. 查询表信息

select status from TABLE where id=1 for update;

# 3. 插入一条数据

insert into TABLE (id,value) values (2,2);

# 4. 修改数据为

update TABLE set value=2 where id=1;

# 5. 提交事务

commit;/commit work;

共享锁

共享锁又称读锁 read lock,是读取操作创建的锁。其他用户可以并发读取数据,但任何事务都不能对数据进行修改(获取数据上的排他锁),直到已释放所有共享锁。

如果事务T对数据A加上共享锁后,则其他事务只能对A再加共享锁,不能加排他锁。获得共享锁的事务只能读数据,不能修改数据

打开第一个查询窗口

begin;/begin work;/start transaction;  (三者选一就可以)

SELECT * from TABLE where id = 1  lock in share mode;

然后在另一个查询窗口中,对id为1的数据进行更新

update  TABLE set name="www.souyunku.com" where id =1;

此时,操作界面进入了卡顿状态,过了超时间,提示错误信息

如果在超时前,执行 commit,此更新语句就会成功。

[SQL]update  test_one set name="www.souyunku.com" where id =1;
[Err] 1205 - Lock wait timeout exceeded; try restarting transaction

加上共享锁后,也提示错误信息

update  test_one set name="www.souyunku.com" where id =1 lock in share mode;
[SQL]update  test_one set name="www.souyunku.com" where id =1 lock in share mode;
[Err] 1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'lock in share mode' at line 1

在查询语句后面增加 LOCK IN SHARE MODE,Mysql会对查询结果中的每行都加共享锁,当没有其他线程对查询结果集中的任何一行使用排他锁时,可以成功申请共享锁,否则会被阻塞。其他线程也可以读取使用了共享锁的表,而且这些线程读取的是同一个版本的数据。

加上共享锁后,对于update,insert,delete语句会自动加排它锁。

排它锁

排他锁 exclusive lock(也叫writer lock)又称写锁

排它锁是悲观锁的一种实现,在上面悲观锁也介绍过

若事务 1 对数据对象A加上X锁,事务 1 可以读A也可以修改A,其他事务不能再对A加任何锁,直到事物 1 释放A上的锁。这保证了其他事务在事物 1 释放A上的锁之前不能再读取和修改A。排它锁会阻塞所有的排它锁和共享锁

读取为什么要加读锁呢:防止数据在被读取的时候被别的线程加上写锁,

使用方式:在需要执行的语句后面加上for update就可以了

行锁

行锁又分共享锁排他锁,由字面意思理解,就是给某一行加上锁,也就是一条记录加上锁。

注意:行级锁都是基于索引的,如果一条SQL语句用不到索引是不会使用行级锁的,会使用表级锁。

共享锁:

名词解释:共享锁又叫做读锁,所有的事务只能对其进行读操作不能写操作,加上共享锁后在事务结束之前其他事务只能再加共享锁,除此之外其他任何类型的锁都不能再加了。

SELECT * from TABLE where id = "1"  lock in share mode;  结果集的数据都会加共享锁

排他锁:

名词解释:若某个事物对某一行加上了排他锁,只能这个事务对其进行读写,在此事务结束之前,其他事务不能对其进行加任何锁,其他进程可以读取,不能进行写操作,需等待其释放。

select status from TABLE where id=1 for update;

可以参考之前演示的共享锁,排它锁语句

由于对于表中,id字段为主键,就也相当于索引。执行加锁时,会将id这个索引为1的记录加上锁,那么这个锁就是行锁。

表锁

如何加表锁

innodb 的行锁是在有索引的情况下,没有索引的表是锁定全表的.

Innodb中的行锁与表锁

前面提到过,在Innodb引擎中既支持行锁也支持表锁,那么什么时候会锁住整张表,什么时候或只锁住一行呢?
只有通过索引条件检索数据,InnoDB才使用行级锁,否则,InnoDB将使用表锁!

在实际应用中,要特别注意InnoDB行锁的这一特性,不然的话,可能导致大量的锁冲突,从而影响并发性能。

行级锁都是基于索引的,如果一条SQL语句用不到索引是不会使用行级锁的,会使用表级锁。行级锁的缺点是:由于需要请求大量的锁资源,所以速度慢,内存消耗大。

死锁

死锁(Deadlock) 
所谓死锁:是指两个或两个以上的进程在执行过程中,因争夺资源而造成的一种互相等待的现象,若无外力作用,它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁,这些永远在互相等待的进程称为死锁进程。由于资源占用是互斥的,当某个进程提出申请资源后,使得有关进程在无外力协助下,永远分配不到必需的资源而无法继续运行,这就产生了一种特殊现象死锁。

解除正在死锁的状态有两种方法:

第一种

1.查询是否锁表

show OPEN TABLES where In_use > 0;

2.查询进程(如果您有SUPER权限,您可以看到所有线程。否则,您只能看到您自己的线程)

show processlist

3.杀死进程id(就是上面命令的id列)

kill id

第二种

1:查看当前的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

2:查看当前锁定的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

3:查看当前等锁的事务

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS; 

杀死进程

kill 进程ID

如果系统资源充足,进程的资源请求都能够得到满足,死锁出现的可能性就很低,否则就会因争夺有限的资源而陷入死锁。其次,进程运行推进顺序与速度不同,也可能产生死锁。
产生死锁的四个必要条件:

(1) 互斥条件:一个资源每次只能被一个进程使用。
(2) 请求与保持条件:一个进程因请求资源而阻塞时,对已获得的资源保持不放。
(3) 不剥夺条件:进程已获得的资源,在末使用完之前,不能强行剥夺。
(4) 循环等待条件:若干进程之间形成一种头尾相接的循环等待资源关系。

虽然不能完全避免死锁,但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销,因为只有很少的事务回滚,而回滚会取消事务执行的所有工作。由于死锁时回滚而由应用程序重新提交。

下列方法有助于最大限度地降低死锁:

(1)按同一顺序访问对象。
(2)避免事务中的用户交互。
(3)保持事务简短并在一个批处理中。
(4)使用低隔离级别。
(5)使用绑定连接。

参考 :

https://blog.csdn.net/puhaiyang/article/details/72284702

https://www.jb51.net/article/78088.htm

图片描述

查看原文

arunfung 收藏了文章 · 4月20日

Redis常见7种使用场景(PHP实战)

Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库,并提供多种语言的API。

本篇文章,主要介绍利用PHP使用Redis,主要的应用场景。

简单字符串缓存实战
$redis->connect('127.0.0.1', 6379);
$strCacheKey  = 'Test_bihu';

//SET 应用
$arrCacheData = [
    'name' => 'job',
    'sex'  => '男',
    'age'  => '30'
];
$redis->set($strCacheKey, json_encode($arrCacheData));
$redis->expire($strCacheKey, 30);  # 设置30秒后过期
$json_data = $redis->get($strCacheKey);
$data = json_decode($json_data);
print_r($data->age); //输出数据

//HSET 应用
$arrWebSite = [
    'google' => [
        'google.com',
        'google.com.hk'
    ],
];
$redis->hSet($strCacheKey, 'google', json_encode($arrWebSite['google']));
$json_data = $redis->hGet($strCacheKey, 'google');
$data = json_decode($json_data);
print_r($data); //输出数据
简单队列实战

$redis->connect('127.0.0.1', 6379);
$strQueueName  = 'Test_bihu_queue';

//进队列
$redis->rpush($strQueueName, json_encode(['uid' => 1,'name' => 'Job']));
$redis->rpush($strQueueName, json_encode(['uid' => 2,'name' => 'Tom']));
$redis->rpush($strQueueName, json_encode(['uid' => 3,'name' => 'John']));
echo "---- 进队列成功 ---- <br /><br />";

//查看队列
$strCount = $redis->lrange($strQueueName, 0, -1);
echo "当前队列数据为: <br />";
print_r($strCount);

//出队列
$redis->lpop($strQueueName);
echo "<br /><br /> ---- 出队列成功 ---- <br /><br />";

//查看队列
$strCount = $redis->lrange($strQueueName, 0, -1);
echo "当前队列数据为: <br />";
print_r($strCount);
简单发布订阅实战
//以下是 pub.php 文件的内容 cli下运行
ini_set('default_socket_timeout', -1);
$redis->connect('127.0.0.1', 6379);
$strChannel = 'Test_bihu_channel';

//发布
$redis->publish($strChannel, "来自{$strChannel}频道的推送");
echo "---- {$strChannel} ---- 频道消息推送成功~ <br/>";
$redis->close();
//以下是 sub.php 文件内容 cli下运行
ini_set('default_socket_timeout', -1);
$redis->connect('127.0.0.1', 6379);
$strChannel = 'Test_bihu_channel';

//订阅
echo "---- 订阅{$strChannel}这个频道,等待消息推送...----  <br/><br/>";
$redis->subscribe([$strChannel], 'callBackFun');
function callBackFun($redis, $channel, $msg)
{
    print_r([
        'redis'   => $redis,
        'channel' => $channel,
        'msg'     => $msg
    ]);
}
简单计数器实战
$redis->connect('127.0.0.1', 6379);
$strKey = 'Test_bihu_comments';

//设置初始值
$redis->set($strKey, 0);

$redis->INCR($strKey);  //+1
$redis->INCR($strKey);  //+1
$redis->INCR($strKey);  //+1

$strNowCount = $redis->get($strKey);

echo "---- 当前数量为{$strNowCount}。 ---- ";
排行榜实战
$redis->connect('127.0.0.1', 6379);
$strKey = 'Test_bihu_score';

//存储数据
$redis->zadd($strKey, '50', json_encode(['name' => 'Tom']));
$redis->zadd($strKey, '70', json_encode(['name' => 'John']));
$redis->zadd($strKey, '90', json_encode(['name' => 'Jerry']));
$redis->zadd($strKey, '30', json_encode(['name' => 'Job']));
$redis->zadd($strKey, '100', json_encode(['name' => 'LiMing']));

$dataOne = $redis->ZREVRANGE($strKey, 0, -1, true);
echo "---- {$strKey}由大到小的排序 ---- <br /><br />";
print_r($dataOne);

$dataTwo = $redis->ZRANGE($strKey, 0, -1, true);
echo "<br /><br />---- {$strKey}由小到大的排序 ---- <br /><br />";
print_r($dataTwo);
简单字符串悲观锁实战

解释:悲观锁(Pessimistic Lock), 顾名思义,就是很悲观。

每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁。

场景:如果项目中使用了缓存且对缓存设置了超时时间。

当并发量比较大的时候,如果没有锁机制,那么缓存过期的瞬间,

大量并发请求会穿透缓存直接查询数据库,造成雪崩效应。

/**
 * 获取锁
 * @param  String  $key    锁标识
 * @param  Int     $expire 锁过期时间
 * @return Boolean
 */
public function lock($key = '', $expire = 5) {
    $is_lock = $this->_redis->setnx($key, time()+$expire);
    //不能获取锁
    if(!$is_lock){
        //判断锁是否过期
        $lock_time = $this->_redis->get($key);
        //锁已过期,删除锁,重新获取
        if (time() > $lock_time) {
            unlock($key);
            $is_lock = $this->_redis->setnx($key, time() + $expire);
        }
    }

    return $is_lock? true : false;
}

/**
 * 释放锁
 * @param  String  $key 锁标识
 * @return Boolean
 */
public function unlock($key = ''){
    return $this->_redis->del($key);
}

// 定义锁标识
$key = 'Test_bihu_lock';

// 获取锁
$is_lock = lock($key, 10);
if ($is_lock) {
    echo 'get lock success<br>';
    echo 'do sth..<br>';
    sleep(5);
    echo 'success<br>';
    unlock($key);
} else { //获取锁失败
    echo 'request too frequently<br>';
}
简单事务的乐观锁实战

解释:乐观锁(Optimistic Lock), 顾名思义,就是很乐观。

每次去拿数据的时候都认为别人不会修改,所以不会上锁。

watch命令会监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败。

也可以调用watch多次监视多个key。这样就可以对指定的key加乐观锁了。

注意watch的key是对整个连接有效的,事务也一样。

如果连接断开,监视和事务都会被自动清除。

当然了exec,discard,unwatch命令都会清除连接中的所有监视。

$strKey = 'Test_bihu_age';

$redis->set($strKey,10);

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- <br/><br/>";

$redis->watch($strKey);

// 开启事务
$redis->multi();

//在这个时候新开了一个新会话执行
$redis->set($strKey,30);  //新会话

echo "---- Current Age:{$age} ---- <br/><br/>"; //30

$redis->set($strKey,20);

$redis->exec();

$age = $redis->get($strKey);

echo "---- Current Age:{$age} ---- <br/><br/>"; //30

//当exec时候如果监视的key从调用watch后发生过变化,则整个事务会失败

推荐阅读

一起学习

查看原文

arunfung 收藏了文章 · 4月20日

mysql 幻读的详解、实例及解决办法

脏读/不可重复读的概念都比较容易理解和掌握,这里不在讨论

事务隔离级别(tx_isolation)

mysql 有四级事务隔离级别 每个级别都有字符或数字编号

级别symbol描述
读未提交READ-UNCOMMITTED0存在脏读、不可重复读、幻读的问题
读已提交READ-COMMITTED1解决脏读的问题,存在不可重复读、幻读的问题
可重复读REPEATABLE-READ2mysql 默认级别,解决脏读、不可重复读的问题,存在幻读的问题。使用 MMVC机制 实现可重复读
序列化SERIALIZABLE3解决脏读、不可重复读、幻读,可保证事务安全,但完全串行执行,性能最低

我们可以通过以下命令 查看/设置 全局/会话 的事务隔离级别

mysql> SELECT @@global.tx_isolation, @@tx_isolation;
+-----------------------+------------------+
| @@global.tx_isolation | @@tx_isolation   |
+-----------------------+------------------+
| REPEATABLE-READ       | READ-UNCOMMITTED |
+-----------------------+------------------+
1 row in set (0.00 sec)

# 设定全局的隔离级别 设定会话 global 替换为 session 即可 把set语法温习一下
# SET [GLOABL] config_name = 'foobar';
# SET @@[session.|global.]config_name = 'foobar';
# SELECT @@[global.]config_name;

SET @@gloabl.tx_isolation = 0;
SET @@gloabl.tx_isolation = 'READ-UNCOMMITTED';

SET @@gloabl.tx_isolation = 1;
SET @@gloabl.tx_isolation = 'READ-COMMITTED';

SET @@gloabl.tx_isolation = 2;
SET @@gloabl.tx_isolation = 'REPEATABLE-READ';

SET @@gloabl.tx_isolation = 3;
SET @@gloabl.tx_isolation = 'SERIALIZABLE';

幻读

首先我们要搞明白何谓幻读,目前网上的众多解释幻读的博文个人感觉仔细设想一下就能找出推翻的例子,就像博文把 非阻塞IO 等同为 异步IO,然后好多文章都纷纷借用,其实这俩货是完全不同,非阻塞IO 是 同步IO 中的一种模式,并非 异步IO。错误的观点都被大众认同的 "正确化" 了,扯远了,回归主题。

幻读会在 RU / RC / RR 级别下出现,SERIALIZABLE 则杜绝了幻读,但 RU / RC 下还会存在脏读,不可重复读,故我们就以 RR 级别来研究幻读,排除其他干扰。

注意:RR 级别下存在幻读的可能,但也是可以使用对记录手动加 X锁 的方法消除幻读。SERIALIZABLE 正是对所有事务都加 X锁 才杜绝了幻读,但很多场景下我们的业务sql并不会存在幻读的风险。SERIALIZABLE 的一刀切虽然事务绝对安全,但性能会有很多不必要的损失。故可以在 RR 下根据业务需求决定是否加锁,存在幻读风险我们加锁,不存在就不加锁,事务安全与性能兼备,这也是 RR 作为mysql默认隔是个事务离级别的原因,所以需要正确的理解幻读。

幻读错误的理解:说幻读是 事务A 执行两次 select 操作得到不同的数据集,即 select 1 得到 10 条记录,select 2 得到 11 条记录。这其实并不是幻读,这是不可重复读的一种,只会在 R-U R-C 级别下出现,而在 mysql 默认的 RR 隔离级别是不会出现的。

这里给出我对幻读的比较白话的理解:

幻读,并不是说两次读取获取的结果集不同,幻读侧重的方面是某一次的 select 操作得到的结果所表征的数据状态无法支撑后续的业务操作。更为具体一些:select 某记录是否存在,不存在,准备插入此记录,但执行 insert 时发现此记录已存在,无法插入,此时就发生了幻读。

这里给出 mysql 幻读的比较形象的场景(借用我在知乎上的回答):

table users: id primary key

事务T1

图片描述
事务T2
图片描述

step1 T1: SELECT * FROM `users` WHERE `id` = 1;
step2 T2: INSERT INTO `users` VALUES (1, 'big cat');
step3 T1: INSERT INTO `users` VALUES (1, 'big cat');
step4 T1: SELECT * FROM `users` WHERE `id` = 1;

T1 :主事务,检测表中是否有 id 为 1 的记录,没有则插入,这是我们期望的正常业务逻辑。

T2 :干扰事务,目的在于扰乱 T1 的正常的事务执行。

在 RR 隔离级别下,step1、step2 是会正常执行的,step3 则会报错主键冲突,对于 T1 的业务来说是执行失败的,这里 T1 就是发生了幻读,因为 T1 在 step1 中读取的数据状态并不能支撑后续的业务操作,T1:“见鬼了,我刚才读到的结果应该可以支持我这样操作才对啊,为什么现在不可以”。T1 不敢相信的又执行了 step4,发现和 setp1 读取的结果是一样的(RR下的 MMVC机制)。此时,幻读无疑已经发生,T1 无论读取多少次,都查不到 id = 1 的记录,但它的确无法插入这条他通过读取来认定不存在的记录(此数据已被T2插入),对于 T1 来说,它幻读了。

其实 RR 也是可以避免幻读的,通过对 select 操作手动加 行X锁(SELECT ... FOR UPDATE 这也正是 SERIALIZABLE 隔离级别下会隐式为你做的事情),同时还需要知道,即便当前记录不存在,比如 id = 1 是不存在的,当前事务也会获得一把记录锁(因为InnoDB的行锁锁定的是索引,故记录实体存在与否没关系,存在就加 行X锁,不存在就加 next-key lock间隙X锁),其他事务则无法插入此索引的记录,故杜绝了幻读。

在 SERIALIZABLE 隔离级别下,step1 执行时是会隐式的添加 行(X)锁 / gap(X)锁的,从而 step2 会被阻塞,step3 会正常执行,待 T1 提交后,T2 才能继续执行(主键冲突执行失败),对于 T1 来说业务是正确的,成功的阻塞扼杀了扰乱业务的T2,对于T1来说他前期读取的结果是可以支撑其后续业务的。

所以 mysql 的幻读并非什么读取两次返回结果集不同,而是事务在插入事先检测不存在的记录时,惊奇的发现这些数据已经存在了,之前的检测读获取到的数据如同鬼影一般。

这里要灵活的理解读取的意思,第一次select是读取,第二次的 insert 其实也属于隐式的读取,只不过是在 mysql 的机制中读取的,插入数据也是要先读取一下有没有主键冲突才能决定是否执行插入。

不可重复读侧重表达 读-读,幻读则是说 读-写,用写来证实读的是鬼影。

RR级别下防止幻读

RR级别下只要对 SELECT 操作也手动加行(X)锁即可类似 SERIALIZABLE 级别(它会对 SELECT 隐式加锁),即大家熟知的:

# 这里需要用 X锁, 用 LOCK IN SHARE MODE 拿到 S锁 后我们没办法做 写操作
SELECT `id` FROM `users` WHERE `id` = 1 FOR UPDATE;

如果 id = 1 的记录存在则会被加行(X)锁,如果不存在,则会加 next-lock key / gap 锁(范围行锁),即记录存在与否,mysql 都会对记录应该对应的索引加锁,其他事务是无法再获得做操作的。

这里我们就展示下 id = 1 的记录不存在的场景,FOR UPDATE 也会对此 “记录” 加锁,要明白,InnoDB 的行锁(gap锁是范围行锁,一样的)锁定的是记录所对应的索引,且聚簇索引同记录是直接关系在一起的。
clipboard.png

id = 1 的记录不存在,开始执行事务:
step1: T1 查询 id = 1 的记录并对其加 X锁
step2: T2 插入 id = 1 的记录,被阻塞
step3: T1 插入 id = 1 的记录,成功执行(T2 依然被阻塞中),T1 提交(T2 唤醒但主键冲突执行错误)
T1事务符合业务需求成功执行,T2干扰T1失败。

SERIALIZABLE级别杜绝幻读

在此级别下,我们便不需要对 SELECT 操作显式加锁,InnoDB会自动加锁,事务安全,但性能很低

clipboard.png

step1: T1 查询 id = 2 的记录,InnoDB 会隐式的对齐加 X锁
step2: T2 插入 id = 2 的记录,被阻塞
step3: T1 插入 id = 2 的记录,成功执行(T2 依然被阻塞中)
step4: T1 成功提交(T2 此时唤醒但主键冲突执行错误)
T1事务符合业务需求成功执行,T2干扰T1失败。

总结

RR 级别作为 mysql 事务默认隔离级别,是事务安全与性能的折中,可能也符合二八定律(20%的事务存在幻读的可能,80%的事务没有幻读的风险),我们在正确认识幻读后,便可以根据场景灵活的防止幻读的发生。

SERIALIZABLE 级别则是悲观的认为幻读时刻都会发生,故会自动的隐式的对事务所需资源加排它锁,其他事务访问此资源会被阻塞等待,故事务是安全的,但需要认真考虑性能。

InnoDB的行锁锁定的是索引,而不是记录本身,这一点也需要有清晰的认识,故某索引相同的记录都会被加锁,会造成索引竞争,这就需要我们严格设计业务sql,尽可能的使用主键或唯一索引对记录加锁。索引映射的记录如果存在,加行锁,如果不存在,则会加 next-key lock / gap 锁 / 间隙锁,故InnoDB可以实现事务对某记录的预先占用,如果记录存在,它就是本事务的,如果记录不存在,那它也将是本是无的,只要本是无还在,其他事务就别想占有它。

查看原文

arunfung 收藏了文章 · 4月17日

我本以为你们会写简历

然而并不是

裁员的裁员 , 没裁员的正在准备裁员的路上 . 再加上一些人年终奖也已经骗到手了 , 依据优良传统 , 年后正是很多人辞职奔向更好的骗工资岗位的高峰期 . 所以 , 如何编简历 ( 注意是编 , 不是写 , 我认为编这个字十分有内涵 ) ?

其实编简历并不是一件很难的事情 , 这件事情的本质就是 : 你在向一个同行陌生人介绍你在本行的道行 . 如果你的体系已经将对方笼罩住了 , 你暂时可以控场一波儿( 不代表一定会被录用 ) ; 如果你被对方笼罩住了 , 你就是受虐那个 ( 不代表你不会被录用 ) . 总之就是一句话 :

唬住面试官就要50K , 唬不住面试官就要5K

没想到 , 时至今日 , 我竟然需要写这么一篇题目类似于<老李手把手教你编简历>或<跟着永强学编简历>又或者<于巨柱细说编简历>的教程 .

可见这一届PHPer是多么的差劲 .

先从一个靠谱简历的外观说起 :

  • 首先 , 请使用PDF格式 , 不要用doc , docx , doc* 等拙劣的文档格式 . 原因我还是要解释一下的 , 因为我也当过面试官 , 我见到过各种神奇的doc文档打开后错位 , 乱行 , 甚至乱码 , 极其影响视觉感官 . 大家都挺忙的 , 打开这么一坨乱糟糟的玩意心情就很差 , 直接筛掉 . 我知道怎么说都会有杠精的 : " word怎么可能会乱呢 ? 我在我这里打开就不乱 . " 我不歧视杠精 , 也一视同仁地无私奉献一条友情提示 :

  • 其次 , 请文件名请专业一些 , 请采用 " 姓名 - 职业 - 工作年限.pdf "这种格式来命名你的简历 , 切忌 "简历.pdf" , 有些不讲究的人真是文件名连简历两个字都不是 , 直接就是随机的一坨字符 , 诸如 yhc.docx . 还是那句话 , 大家都挺忙的 , 主要是请尽量多提供信息给好看的HR小姐姐 , 让她们减少一些无畏的工作负担 , 次要是因为你的简历名字一眼让人获取到了很多信息 , 第一时间被捡出来 .

然后 , 更重要的地方来了 , 里面写啥 .

个人认为一个简历四大组成部分 , 根据重要程度依次为 : 一是个人信息部分 , 二是技能点说明部分 , 三是项目经历部分 , 四是公司经历 .

下面按照顺序依次说下我觉得需要注意的地方 , 最后收尾我会提一下这个部分的可修饰程度 . 什么叫可修饰程度 ? ? ?

读书人的事儿 , 能叫偷么 ? --- 孔乙己

先说第一部分 , 个人信息部分 . 你出去大保健被警察叔叔逮进局子后让你交代的啥 , 这里就写啥 . 可修饰程度比较低 , 拥有一丝丝可修饰价值 .

再说第二部分 , 个人技能点分配说明 . 这项十分重要 . 面试官会非常注重这一项 , HR一般看不懂 . 很多人这里写的很差 , 这句话的意思就是 : 内涵不错的人这里写的很差 , 没有内涵的人这里写的也很差 , 以致于"内涵不错的人"从简历上看似乎和"没内涵的人"都差不多 . 这个地方最好不要写" 精通 "这两个字 . 虽然HR有可能真的喜欢简历上有" 精通 "字样的人 , 但是你也要知道你这两个字也会给你的面试官带来极大的反感或嘲讽欲 , 总之 , 你结合你自己情况自己看着办 , 万一你真的精通了呢 ? 然后我说下我见过大多数人这个地方都是怎么编的 , 一般都是 :

熟悉PHP , 熟悉YiiLavarel框架
熟悉Linux使用 , 可以搭建XXXX环境
熟悉git或svn版本管理的使用
熟悉MySQL以及对数据库的优化
熟悉Redis或Memcache的使用

我敢说大多数人都是这么写的 , 下面我站在面试官的立场来用行内白话来解释一下当我看到这样的简历后大脑里怎么想的 .

熟悉PHP , 熟悉YiiLavarel框架 ( 复制粘贴 , CURD , 就是干! )
熟悉Linux使用 , 可以搭建XXXX环境 ( 会敲cd , ls命令 , 会apt install nginx )
熟悉git或svn版本管理的使用 ( 会git push , 会git pull )
熟悉MySQL以及对数据库的优化 ( 会select update 和 delete , 会添加索引 )
熟悉Redis或Memcache的使用 ( 会set key , 会get key )

问题是什么 ? 其实问题不在于这些行内白话没有提现你的水准 . 这个问题的关键是 : 大家都这么写 , 凭啥把你的简历挑出来 .

所以这个地方吧 , 可以尝试用下面来表述 , 注意要结合你自己掌握程度 :

PHP : 熟悉PHP语法 , 熟悉PHP面向对象 , 可以根据业务逻辑结合合适的设计模式 . 熟悉PHP SPL标准库 , 对PHP的一些高级用法有所心得体验 , 诸如pcntl多进程模块 , socket模块 . 对SWOOLE所有涉猎 , 有一些自己的积累和经验 . 对于底层 , ZendVM如何如何 .
Redis : 熟悉Redis常用数据结构的使用 , 可结合业务场景选择合适的数据结构 . 熟悉Redis集群 , 对集群实现方案原理有一定掌握 , 对于市面常用的集中集群方案的优缺点比较了解 . 对于底层 , 对Redis SET等底层数据结构的实现有所掌握 .

行了 , 我就举两个例子吧 , 技能点的说明最好用类似上面的说明 , 还是那句话 : 最好不要出现精通 .

那该用什么形容词呢 ? 我替你总结一下常用的几个词语 : 熟悉 , 有所 , 掌握 , 了解 , 有一定 , 心得 等 .

第二部分 : 可修饰程度略高 , 拥有可修饰价值 . 主要是你要能够应对面试官对修饰部分的问题 .

继续说第三部分 , 项目经历部分 . 这一部分实际上是对第二部分技能点分配说明的实战演练说明 , 你要提现出你在这个项目中的两点 :

  • 亮点 . 你觉得这个项目中哪一部分值得自豪或学到新东西了 . 比如项目中用到ECDH , 使用了MySQL中间件等等 .
  • 难点 . 你觉得这个项目哪一部分当时难了你几天 , 然后你通过自己努力解决了以及解决方案是什么 .

然而大多数人都是这么写的 :

负责用户登录注册模块 , 后台管理 , 多角色权限控制 , 负责广告业务模块的管理和筛查 .

你这么写的 , 别人也是这么写的 .

第三部分 : 可修饰程度比较高 , 拥有较高修饰价值 . 主要是你要能够应对面试官对修饰部分的问题 .

最后一点是公司经历了 , 这个也没啥好说的 . 如果可以 , 我建议你合并一些小公司经历直接合并为一家 . 对于一些少数倒霉的同学 , 比如在不到10个人公司干了三个月就辞职的这种 , 我建议修饰成" 去朋友公司帮他临时组件了一个小团队 ".

然而 , 到了最后 , 我还是要告诉你这个世界多么残酷 , 即便你的简历真的比较优秀 , 用词恰当 , 然而如果你面试遇上了傻逼一样的面试官 , 都白搭 . 这里的傻逼理解为两类 :

  • 装逼优越diss你类型的 . 这种的 , 可能依然会录用你 .
  • 看你不顺眼 , 上来说话就带刺类型的 . 根据你的心理承受能力 , 请你自己做出相应动作 .

不得不承认 , 只要看双方对了眼 , 聊的投机了 , 简历什么的是可以抛到一边儿的 .

找到一个合适的工作是你和这家公司的事儿 : 一个愿打 , 一个愿挨 .
能应聘到这个合适的工作是你和面试官的事儿 : wangba看绿豆 -- 对上眼了 .

最近开了一个微信公众号,所有文章都在这里

图片描述

查看原文

arunfung 收藏了文章 · 3月18日

进阶的Redis之哈希分片原理与集群实战

前面介绍了《进阶的Redis之数据持久化RDB与AOF》《进阶的Redis之Sentinel原理及实战》,这次来了解下Redis的集群功能,以及其中哈希分片原理。

集群分片模式

如果Redis只用复制功能做主从,那么当数据量巨大的情况下,单机情况下可能已经承受不下一份数据,更不用说是主从都要各自保存一份完整的数据。在这种情况下,数据分片是一个非常好的解决办法。

Redis的Cluster正是用于解决该问题。它主要提供两个功能:

  1. 自动对数据分片,落到各个节点上
  2. 即使集群部分节点失效或者连接不上,依然可以继续处理命令

对于第二点,它的功能有点类似于Sentienl的故障转移(可以了解下之前Sentinel的文章),在这里不细说。下面详细了解下Redis的槽位分片原理,在此之前,先了解下分布式简单哈希算法和一致性哈希算法,以帮助理解槽位的作用。

简单哈希算法

假设有三台机,数据落在哪台机的算法为

  c = Hash(key) % 3

例如key A的哈希值为4,4%3=1,则落在第二台机。Key ABC哈希值为11,11%3=2,则落在第三台机上。

利用这样的算法,假设现在数据量太大了,需要增加一台机器。A原本落在第二台上,现在根据算法4%4=0,落到了第一台机器上了,但是第一台机器上根本没有A的值。这样的算法会导致增加机器或减少机器的时候,引起大量的缓存穿透,造成雪崩。

一致性哈希算法

在1997年,麻省理工学院的Karger等人提出了一致性哈希算法,为的就是解决分布式缓存的问题。

一致性哈希算法中,整个哈希空间是一个虚拟圆环

假设有四个节点Node A、B、C、D,经过ip地址的哈希计算,它们的位置如下

有4个存储对象Object A、B、C、D,经过对Key的哈希计算后,它们的位置如下

对于各个Object,它所真正的存储位置是按顺时针找到的第一个存储节点。例如Object A顺时针找到的第一个节点是Node A,所以Node A负责存储Object A,Object B存储在Node B。

一致性哈希算法大概如此,那么它的容错性扩展性如何呢?

假设Node C节点挂掉了,Object C的存储丢失,那么它顺时针找到的最新节点是Node D。也就是说Node C挂掉了,受影响仅仅包括Node B到Node C区间的数据,并且这些数据会转移到Node D进行存储。

同理,假设现在数据量大了,需要增加一台节点Node X。Node X的位置在Node B到Node C直接,那么受到影响的仅仅是Node B到Node X间的数据,它们要重新落到Node X上。

所以一致性哈希算法对于容错性和扩展性有非常好的支持。但一致性哈希算法也有一个严重的问题,就是数据倾斜

如果在分片的集群中,节点太少,并且分布不均,一致性哈希算法就会出现部分节点数据太多,部分节点数据太少。也就是说无法控制节点存储数据的分配。如下图,大部分数据都在A上了,B的数据比较少。

哈希槽

Redis集群(Cluster)并没有选用上面一致性哈希,而是采用了哈希槽(SLOT)的这种概念。主要的原因就是上面所说的,一致性哈希算法对于数据分布、节点位置的控制并不是很友好。

首先哈希槽其实是两个概念,第一个是哈希算法。Redis Cluster的hash算法不是简单的hash(),而是crc16算法,一种校验算法。

另外一个就是槽位的概念,空间分配的规则。其实哈希槽的本质和一致性哈希算法非常相似,不同点就是对于哈希空间的定义。一致性哈希的空间是一个圆环,节点分布是基于圆环的,无法很好的控制数据分布。而Redis Cluster的槽位空间是自定义分配的,类似于Windows盘分区的概念。这种分区是可以自定义大小,自定义位置的。

Redis Cluster包含了16384个哈希槽,每个Key通过计算后都会落在具体一个槽位上,而这个槽位是属于哪个存储节点的,则由用户自己定义分配。例如机器硬盘小的,可以分配少一点槽位,硬盘大的可以分配多一点。如果节点硬盘都差不多则可以平均分配。所以哈希槽这种概念很好地解决了一致性哈希的弊端。

另外在容错性扩展性上,表象与一致性哈希一样,都是对受影响的数据进行转移。而哈希槽本质上是对槽位的转移,把故障节点负责的槽位转移到其他正常的节点上。扩展节点也是一样,把其他节点上的槽位转移到新的节点上。

但一定要注意的是,对于槽位的转移和分派,Redis集群是不会自动进行的,而是需要人工配置的。所以Redis集群的高可用是依赖于节点的主从复制与主从间的自动故障转移。

集群搭建

下面以最简单的例子,抛开高可用主从复制级转移的内容,来重点介绍下Redis集群是如何搭建,槽位是如何分配的,以加深对Redis集群原理及概念的理解。

redis.conf配置

先找到redis.conf,启用cluster功能。

cluster-enabled yes默认是关闭的,要启用cluster,让redis成为集群的一部分,需要手动打开才行。

然后配置cluster的配置文件

每一个cluster节点都有一个cluster的配置文件,这个文件主要用于记录节点信息,用程序自动生成和管理,不需要人工干预。唯一要注意的是,如果在同一台机器上运行多个节点,需要修改这个配置为不同的名字。

本次为了方便搭建,所有Redis实例都在同一台机器上,所以修改不同的cluster config名字后,复制三份redis.conf配置,以用于启动三个集群实例(cluster至少要三个主节点才能进行)。

集群关联

  > redis-server /usr/local/etc/redis/redis-6379.conf --port 6379 &
  > redis-server /usr/local/etc/redis/redis-6380.conf --port 6380 &
  > redis-server /usr/local/etc/redis/redis-6381.conf --port 6381 &

&符号的作用是让命令在后台执行,但程序执行的log依然会打印在console中。也可以通过配置redis.conf中deamonize yes,让Redis在后台运行。

连上6379的Redis实例,然后通过cluster nodes查看集群范围。

连上其他实例也是一样,目前6379、6380、6381在各自的集群中,且集群只有它们自己一个。

在6379上,通过cluster meet命令,与6380、6381建立链接。

  127.0.0.1:6379> cluster meet 127.0.0.1 6380
  127.0.0.1:6379> cluster meet 127.0.0.1 6381


可以看到集群中已经包含了6379、6380、6381三个节点了。登录其他节点查看也是一样的结果。即使6380与6381之间没有直接手动关联,但在集群中,节点一旦发现有未关联的节点,会自动与之握手关联。

槽位分配

通过cluster info命令查看集群的状态

state的状态是fail的,还没启用。看下官方的说明

只有state为ok,节点才能接受请求。如果只要有一个槽位(slot)没有分配,那么这个状态就是fail。而一共需要分配16384槽位才能让集群正常工作。

接下来给6379分配0~5000的槽位,给6380分配5001~10000的槽位,给6381分配10001~16383的槽位。

  > redis-cli -c -p 6379 cluster addslots {0..5000}
  > redis-cli -c -p 6380 cluster addslots {5001..10000}
  > redis-cli -c -p 6381 cluster addslots {10001..16383}

再看看cluster info

state已经为ok,16384个槽位都已经分配好了。现在集群已经可以正常工作了。

效果测试

随便登上一个实例,记得加上参数-c,启用集群模式的客户端,否则无法正常运行。

  redis-cli -c -p 6380

尝试下set、get操作

可以看到,Redis集群会计算key落在哪个卡槽,然后会把命令转发到负责该卡槽的节点上执行。

利用cluster keyslot命令计算出key是在哪个槽位上,从而得出会跳转到哪个节点上执行。


更多技术文章、精彩干货,请关注
博客:zackku.com
微信公众号:Zack说码

查看原文

arunfung 发布了文章 · 2月11日

【swoole 学习笔记】虚拟机 CentOS7 配置 IP

CentOS7 IP配置

网络连接方式建议更换成桥接网卡
CentOS7的查看IP已经和低版本不一样了

# 查看ip信息
ip addr

# 对应存放网卡配置的地方,找到自己对应的网卡名
cd /etc/sysconfig/network-scripts

# 我这是 enp0s3 所以对应的是 ifcfg-enp0s3
快速查看当前网卡
$ ip link | awk 'NR%2==1' | awk '{print $2,$8,$9}' | tr -d ':'
输出:第二个就是网卡设备
lo state UNKNOWN
enp0s3 state UP

# 打开 ifcfg-enp0s3 网卡配置文件
vi ifcfg-enp0s3

# 修改配置
ONBOOT=no -> ONBOOT=yes

# 重启网络(两个命令都可以)
service network restart
systemctl restart network

# 如果经常重启电脑或虚拟机可能会导致ip变更,可以自行绑定一个同网段的ip比如127

#ZONE=public
#IPADDR=192.168.6.127 # centos的ip地址
#NETMASK=255.255.255.0 # 子网掩码
#GATEWAY=192.168.6.2 # 网关

# 重启过后就可以查看到对应的ip了,尝试ping一下ip,如果通的,就可以使用终端连接了

查看原文

赞 0 收藏 0 评论 0

arunfung 发布了文章 · 2月11日

【swoole 学习笔记】VirtualBox 6.1 安装 CentOS7 虚拟主机

介绍

需求:在本地运行一套和线上一样的环境,用于本地开发使用

  • VirtualBox 是一款可以运行Windows、Mac、Linux操作系统,功能强大的开源虚拟机软件
  • CentOS 是 Linux 操作系统

准备

  • 从 VirtualBox 官网下载并安装好,安装后打开是以下这样的:

  • 下载一个 CentOS 镜像,最好下载 minimal 版本,只带命令行就够了

开始安装

tips:可以将 VirtualBox 软件设置成中文,preferences-》language-》简体中文

1. 创建虚拟机

点击新建(new) -》输入名称 centos -》 会自动调整类型和版本 -》然后点继续

1. 设置内存

根据自己机器内存大小设置,以及同时启动几个虚拟主机,我这边设置 1G(默认1024M)-》然后点击继续

1. 创建虚拟硬盘

默认现在创建,点击创建-》虚拟硬盘文件类型默认,点继续-》存储在硬盘上默认动态分配,点击继续-》文件位置和大小,默认,点击创建

虚拟主机创建成功,接下来还要对刚创建的主机进行设置,

1. 设置虚拟主机

点击刚创建的虚拟机-》点击系统

启动顺序将软驱调整为最后一位

选择存储tab,1点击没有盘片-》2点击小圆-》选择本地硬盘上的 CentOS 镜像-》然后点击OK

网络选择桥接网卡

1. 启动虚拟主机

选择创建的虚拟主机,点击启动-》弹出询问继续点启动

默认回车安装

设置语言,默认英语,点击继续吧(continue)

设置下地区和时间

选择亚洲和上海,然后点击完成(done)

设置存储在哪,点击进入选择

1选择刚创建的虚拟硬盘-》2点击完成

点击开始安装

在安装的过程中需要设置一个root密码,也可以一并设置一个新用户

然后就静静的等待安装完成吧,最后点击 reboot 重启即可

如需查看ip配置请查看虚拟机 CentOS7 配置IP

查看原文

赞 0 收藏 0 评论 0

arunfung 发布了文章 · 2月11日

分层数据 Hierarchical Data 探索 (3.嵌套集合模型) 无限极分类

分层数据Hierarchical Data探索(例如:无限级分类、多级菜单、省份城市)

引言

第一篇 分层数据Hierarchical Data探索(1.递归) 已经介绍了分层数据以及使用递归算法实现了无限极分类,但是递归即浪费时间,又浪费空间(内存),尤其是在数据量大的情况下效率显著下降。
第二篇 分层数据Hierarchical Data探索(2.邻接表模型) 介绍了一种数据模型邻接表模型来实现,但在检索路径的过程中,除了本层外,每一层都会对应一个LEFT JOIN,那么如果层数不定怎么办?或者层数过多?

邻接表模型的局限性

用纯SQL编码实现邻接表模型有一定的难度。在我们检索某分类的路径之前,我们需要知道该分类所在的层次。在删除中间层的节点时,需要同时删除该节点下的所有节点,否则会出现孤立节点。

那么,在MySQL中如何更好的处理分层数据呢?下面我们来说一说嵌套集合模型

嵌套集合模型(Nested Set Model)

更多 嵌套集合模型(Nested Set Model)的介绍请见:wiki

在嵌套集合模型中,我们将以一种新的方式来理解我们的分层数据,不再是线与点了,而是嵌套容器。下图以嵌套容器的方式画出了electronics分类图:

通过集合的包含关系,嵌套结合模型可以表示分层结构,每一个分层可以用一个Set来表示(一个圈),父节点所在的圈包含所有子节点所在的圈。

为了用MySQL来表示集合关系,需要定义连个字段 lftrgt (表示一个集合的范围)。

# 为了模拟,我们创建一个表category包含三个字段:id,title,lft,rgt如下:
CREATE TABLE category (
  id int(10) unsigned NOT NULL AUTO_INCREMENT PRIMARY KEY,
  title varchar(255) NOT NULL,
  lft int(10) NOT NULL,
  rgt int(10) NOT NULL
);

# 插入模拟数据
INSERT INTO category(title,lft,rgt) VALUES('Electronics',1,28);

INSERT INTO category(title,lft,rgt) VALUES('Laptops & PC',2,7);
 
INSERT INTO category(title,lft,rgt) VALUES('Laptops',3,4);
INSERT INTO category(title,lft,rgt) VALUES('PC',5,6);
 
INSERT INTO category(title,lft,rgt) VALUES('Cameras & photo',8,11);
INSERT INTO category(title,lft,rgt) VALUES('Camera',9,10);
 
INSERT INTO category(title,lft,rgt) VALUES('Phones & Accessories',12,27);
INSERT INTO category(title,lft,rgt) VALUES('Smartphones',13,20);
 
INSERT INTO category(title,lft,rgt) VALUES('Android',14,15);
INSERT INTO category(title,lft,rgt) VALUES('iOS',16,17);
INSERT INTO category(title,lft,rgt) VALUES('Other Smartphones',18,19);
 
INSERT INTO category(title,lft,rgt) VALUES('Batteries',21,22);
INSERT INTO category(title,lft,rgt) VALUES('Headsets',23,24);
INSERT INTO category(title,lft,rgt) VALUES('Screen Protectors',25,26);

select * from category;
+----+----------------------+-----+-----+
| id | title                | lft | rgt |
+----+----------------------+-----+-----+
|  1 | Electronics          |   1 |  28 |
|  2 | Laptops & PC         |   2 |   7 |
|  3 | Laptops              |   3 |   4 |
|  4 | PC                   |   5 |   6 |
|  5 | Cameras & photo      |   8 |  11 |
|  6 | Camera               |   9 |  10 |
|  7 | Phones & Accessories |  12 |  27 |
|  8 | Smartphones          |  13 |  20 |
|  9 | Android              |  14 |  15 |
| 10 | iOS                  |  16 |  17 |
| 11 | Other Smartphones    |  18 |  19 |
| 12 | Batteries            |  21 |  22 |
| 13 | Headsets             |  23 |  24 |
| 14 | Screen Protectors    |  25 |  26 |
+----+----------------------+-----+-----+
14 rows in set (0.00 sec)
  • 检索分层路径

由于子节点的 lft 值总在父节点的 lft 和 rgt 值之间,所以可以通过父节点连接到子节点上来检索整棵树

SELECT node.id,node.title,node.lft,node.rgt
FROM category AS node,
     category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
        AND parent.title = 'Electronics'
ORDER BY node.lft;
+----+----------------------+-----+-----+
| id | title                | lft | rgt |
+----+----------------------+-----+-----+
|  1 | Electronics          |   1 |  28 |
|  2 | Laptops & PC         |   2 |   7 |
|  3 | Laptops              |   3 |   4 |
|  4 | PC                   |   5 |   6 |
|  5 | Cameras & photo      |   8 |  11 |
|  6 | Camera               |   9 |  10 |
|  7 | Phones & Accessories |  12 |  27 |
|  8 | Smartphones          |  13 |  20 |
|  9 | Android              |  14 |  15 |
| 10 | iOS                  |  16 |  17 |
| 11 | Other Smartphones    |  18 |  19 |
| 12 | Batteries            |  21 |  22 |
| 13 | Headsets             |  23 |  24 |
| 14 | Screen Protectors    |  25 |  26 |
+----+----------------------+-----+-----+
14 rows in set (0.05 sec)

不像之前邻接表模型的例子,这个查询语句不管树的层次有多深都能很好的工作。在BETWEEN的子句中我们没有去关心node的rgt值,是因为使用node的rgt值得出的父节点总是和使用lft值得出的是相同的。

  • 检索所有叶子节点

检索出所有的叶子节点,使用嵌套集合模型的方法比邻接表模型的LEFT JOIN方法简单多了。如果你仔细得看了category表,你可能已经注意到叶子节点的左右值是连续的。要检索出叶子节点,我们只要查找满足 rgt=lft+1 的节点:

SELECT id,title,lft,rgt
FROM category
WHERE rgt = lft + 1;
+----+-------------------+-----+-----+
| id | title             | lft | rgt |
+----+-------------------+-----+-----+
|  3 | Laptops           |   3 |   4 |
|  4 | PC                |   5 |   6 |
|  6 | Camera            |   9 |  10 |
|  9 | Android           |  14 |  15 |
| 10 | iOS               |  16 |  17 |
| 11 | Other Smartphones |  18 |  19 |
| 12 | Batteries         |  21 |  22 |
| 13 | Headsets          |  23 |  24 |
| 14 | Screen Protectors |  25 |  26 |
+----+-------------------+-----+-----+
9 rows in set (0.00 sec)

查询

  • 检索单一路径

在嵌套集合模型中,我们可以不用多个自连接就可以检索出单一路径:

SELECT parent.id,parent.title,parent.lft,parent.rgt
FROM category AS node,
     category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
        AND node.title = 'PC'
ORDER BY parent.lft;

+----+--------------+-----+-----+
| id | title        | lft | rgt |
+----+--------------+-----+-----+
|  1 | Electronics  |   1 |  28 |
|  2 | Laptops & PC |   2 |   7 |
|  4 | PC           |   5 |   6 |
+----+--------------+-----+-----+
3 rows in set (0.00 sec)
  • 检索节点的深度

我们已经知道怎样去呈现一棵整树,但是为了更好的标识出节点在树中所处层次,我们怎样才能检索出节点在树中的层级呢?我们可以在之前的查询语句上增加COUNT函数和GROUP BY子句来实现:

SELECT node.title,(COUNT(parent.title) - 1) AS lev
FROM category AS node,
     category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
GROUP BY node.title
ORDER BY node.lft;

+----------------------+-----+
| title                | lev |
+----------------------+-----+
| Electronics          |   0 |
| Laptops & PC         |   1 |
| Laptops              |   2 |
| PC                   |   2 |
| Cameras & photo      |   1 |
| Camera               |   2 |
| Phones & Accessories |   1 |
| Smartphones          |   2 |
| Android              |   3 |
| iOS                  |   3 |
| Other Smartphones    |   3 |
| Batteries            |   2 |
| Headsets             |   2 |
| Screen Protectors    |   2 |
+----------------------+-----+
14 rows in set (0.01 sec)
如果当前MySQL版本是5.7或者以上可能会出现 1055 的报错,下面是是解决办法
报错:
ERROR 1055 (42000): Expression #1 of ORDER BY clause is not in GROUP BY clause and contains nonaggregated column 'test.node.lft' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

原因:In 5.7 the sqlmode is set by default to:
ONLY_FULL_GROUP_BY,NO_AUTO_CREATE_USER,STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION

解决:To remove the clause ONLY_FULL_GROUP_BY you can do this:
SET sql_mode=(SELECT REPLACE(@@sql_mode,'ONLY_FULL_GROUP_BY',''));

This supposed you need to make that GROUP BY with non aggregated columns.

我们可以根据 lev 值来缩进分类名字,使用 CONCAT 和 REPEAT 字符串函数:

SELECT CONCAT( REPEAT(' ', COUNT(parent.title) - 1), node.title) AS name,(COUNT(parent.title) - 1) AS lev
FROM category AS node,
     category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
GROUP BY node.title
ORDER BY node.lft;
+-----------------------+-----+
| name                  | lev |
+-----------------------+-----+
| Electronics           |   0 |
|  Laptops & PC         |   1 |
|   Laptops             |   2 |
|   PC                  |   2 |
|  Cameras & photo      |   1 |
|   Camera              |   2 |
|  Phones & Accessories |   1 |
|   Smartphones         |   2 |
|    Android            |   3 |
|    iOS                |   3 |
|    Other Smartphones  |   3 |
|   Batteries           |   2 |
|   Headsets            |   2 |
|   Screen Protectors   |   2 |
+-----------------------+-----+
14 rows in set (0.01 sec)
  • 检索子树的深度
SELECT node.title, (COUNT(parent.title) - (sub_tree.lev + 1)) AS lev
FROM category AS node,
    category AS parent,
    category AS sub_parent,
    (
        SELECT node.title, (COUNT(parent.title) - 1) AS lev
        FROM category AS node,
        category AS parent
        WHERE node.lft BETWEEN parent.lft AND parent.rgt
        AND node.title = 'Phones & Accessories'
        GROUP BY node.title
        ORDER BY node.lft
    ) AS sub_tree
WHERE node.lft BETWEEN parent.lft AND parent.rgt
    AND node.lft BETWEEN sub_parent.lft AND sub_parent.rgt
    AND sub_parent.title = sub_tree.title
GROUP BY node.title
ORDER BY node.lft;

这个查询语句可以检索出任一节点子树的深度值,包括根节点。这里的深度值跟你指定的节点有关。

  • 检索节点的直接子节点

可以想象一下,你在零售网站上呈现电子产品的分类。当用户点击分类后,你将要呈现该分类下的产品,同时也需列出该分类下的直接子分类,而不是该分类下的全部分类。为此,我们只呈现该节点及其直接子节点,不再呈现更深层次的节点。
要实现它非常的简单,在先前的查询语句上添加 HAVING 子句:

SELECT node.title, (COUNT(parent.title) - (sub_tree.lev + 1)) AS lev
FROM category AS node,
    category AS parent,
    category AS sub_parent,
    (
        SELECT node.title, (COUNT(parent.title) - 1) AS lev
        FROM category AS node,
        category AS parent
        WHERE node.lft BETWEEN parent.lft AND parent.rgt
        AND node.title = 'Phones & Accessories'
        GROUP BY node.title
        ORDER BY node.lft
    ) AS sub_tree
WHERE node.lft BETWEEN parent.lft AND parent.rgt
    AND node.lft BETWEEN sub_parent.lft AND sub_parent.rgt
    AND sub_parent.title = sub_tree.title
GROUP BY node.title
HAVING lev <= 1
ORDER BY node.lft;

如果你不希望呈现父节点,你可以更改 HAVING lev <= 1HAVING lev = 1

新增节点

  • 添加同一层次的节点

到现在,我们已经知道了如何去查询我们的树,是时候关注一下如何增加一个新节点来更新我们的树了。
当我们想要在 Laptops & PCCameras & photo节点之间新增一个节点,新节点的 lft 和 rgt 的 值为8和9,所有该节点的右边节点的lft和rgt值都将加2,之后我们再添加新节点并赋相应的lft和rgt值。我使用了锁表(LOCK TABLES)语句来隔离查询:

LOCK TABLE category WRITE;

SELECT @myRight := rgt FROM category WHERE title = 'Laptops & PC';

UPDATE category SET rgt = rgt + 2 WHERE rgt > @myRight;
UPDATE category SET lft = lft + 2 WHERE lft > @myRight;

INSERT INTO category(title, lft, rgt) VALUES('Game Consoles', @myRight + 1, @myRight + 2);

UNLOCK TABLES;

我们可以检验一下新节点插入的正确性:
SELECT CONCAT( REPEAT(' ', COUNT(parent.title) - 1), node.title) AS name,(COUNT(parent.title) - 1) AS lev
FROM category AS node,
     category AS parent
WHERE node.lft BETWEEN parent.lft AND parent.rgt
GROUP BY node.title
ORDER BY node.lft;

+-----------------------+-----+
| name                  | lev |
+-----------------------+-----+
| Electronics           |   0 |
|  Laptops & PC         |   1 |
|   Laptops             |   2 |
|   PC                  |   2 |
|  Game Consoles        |   1 |
|  Cameras & photo      |   1 |
|   Camera              |   2 |
|  Phones & Accessories |   1 |
|   Smartphones         |   2 |
|    Android            |   3 |
|    iOS                |   3 |
|    Other Smartphones  |   3 |
|   Batteries           |   2 |
|   Headsets            |   2 |
|   Screen Protectors   |   2 |
+-----------------------+-----+
15 rows in set (0.00 sec)
  • 添加叶子节点

如果我们想要在叶子节点下增加节点,我们得稍微修改一下查询语句。让我们在 Camera 叶子节点下添加 SLR 节点:

LOCK TABLE category WRITE;

SELECT @myLeft := lft FROM category WHERE title = 'Camera';

UPDATE category SET rgt = rgt + 2 WHERE rgt > @myLeft;
UPDATE category SET lft = lft + 2 WHERE lft > @myLeft;

INSERT INTO category(title, lft, rgt) VALUES('SLR', @myLeft + 1, @myLeft + 2);

UNLOCK TABLES;

删除节点

最后删除节点。删除节点的处理过程跟节点在分层数据中所处的位置有关,删除一个叶子节点比删除一个子节点要简单得多,因为删除子节点的时候,我们需要去处理孤立节点。

  • 删除叶子节点

删除一个叶子节点的过程正好是新增一个叶子节点的逆过程,我们在删除节点的同时该节点右边所有节点的左右值和该父节点的右值都会减去该节点的宽度值:

LOCK TABLE category WRITE;


SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1 FROM category WHERE title = 'Game Consoles';


DELETE FROM category WHERE lft BETWEEN @myLeft AND @myRight;


UPDATE category SET rgt = rgt - @myWidth WHERE rgt > @myRight;
UPDATE category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;
  • 删除子节点以及整颗子树
LOCK TABLE category WRITE;


SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1 FROM category WHERE title = 'Cameras & photo';


DELETE FROM category WHERE lft BETWEEN @myLeft AND @myRight;


UPDATE category SET rgt = rgt - @myWidth WHERE rgt > @myRight;
UPDATE category SET lft = lft - @myWidth WHERE lft > @myRight;

UNLOCK TABLES;
  • 删除该节点,而不删除该节点的子节点
LOCK TABLE category WRITE;


SELECT @myLeft := lft, @myRight := rgt, @myWidth := rgt - lft + 1 FROM category WHERE title = 'Cameras & photo';


DELETE FROM category WHERE lft = @myLeft;


UPDATE category SET rgt = rgt - 1, lft = lft - 1 WHERE lft BETWEEN @myLeft AND @myRight;
UPDATE category SET rgt = rgt - 2 WHERE rgt > @myRight;
UPDATE category SET lft = lft - 2 WHERE lft > @myRight;

UNLOCK TABLES;

在这个例子中,我们对该节点所有右边节点的左右值都减去了2(因为不考虑其子节点,该节点的宽度为2),对该节点的子节点的左右值都减去了1(弥补由于失去父节点的左值造成的裂缝)

参考资源

查看原文

赞 0 收藏 0 评论 0

arunfung 关注了专栏 · 1月12日

腾讯云技术社区

最专业的云解读社区

关注 11482

arunfung 收藏了文章 · 2019-11-19

深入解析 composer 的自动加载原理

深入解析 composer 的自动加载原理

前言

PHP 自5.3的版本之后,已经重焕新生,命名空间、性状(trait)、闭包、接口、PSR 规范、以及 composer 的出现已经让 PHP 变成了一门现代化的脚本语言。PHP 的生态系统也一直在演进,而 composer 的出现更是彻底的改变了以往构建 PHP 应用的方式,我们可以根据 PHP 的应用需求混合搭配最合适的 PHP 组件。当然这也得益于 PSR 规范的提出。


大纲

  • PHP 自动加载功能
  • PSR 规范
  • comoposer 的自动加载过程
  • composer 源码分析

一、PHP 自动加载功能

PHP 自动加载功能的由来

在 PHP 开发过程中,如果希望从外部引入一个 Class ,通常会使用 includerequire 方法,去把定义这个 Class 的文件包含进来。这个在小规模开发的时候,没什么大问题。但在大型的开发项目中,使用这种方式会带来一些隐含的问题:如果一个 PHP 文件需要使用很多其它类,那么就需要很多的 require/include 语句,这样有可能会 造成遗漏 或者 包含进不必要的类文件。如果大量的文件都需要使用其它的类,那么要保证每个文件都包含正确的类文件肯定是一个噩梦, 况且 require或 incloud 的性能代价很大。

PHP5 为这个问题提供了一个解决方案,这就是 类的自动加载(autoload)机制autoload机制 可以使得 PHP 程序有可能在使用类时才自动包含类文件,而不是一开始就将所有的类文件include进来,这种机制也称为 Lazy loading (惰性加载)

  • 总结起来,自动加载功能带来了几处优点:

    1. 使用类之前无需 include / require
    2. 使用类的时候才会 include / require 文件,实现了 lazy loading ,避免了 include / require 多余文件。
    3. 无需考虑引入 类的实际磁盘地址 ,实现了逻辑和实体文件的分离。

PHP 自动加载函数 __autoload()

  • 从 PHP5 开始,当我们在使用一个类时,如果发现这个类没有加载,就会自动运行 __autoload() 函数,这个函数是我们在程序中自定义的,在这个函数中我们可以加载需要使用的类。下面是个简单的示例:

    <?php
    
    function __autoload($classname) {
            require_once ($classname . ".class.php");
    }
  • 在我们这个简单的例子中,我们直接将类名加上扩展名 .class.php 构成了类文件名,然后使用 require_once 将其加载。

    从这个例子中,我们可以看出 __autoload 至少要做三件事情:

    1. 根据类名确定类文件名;
    2. 确定类文件所在的磁盘路径;
    3. 将类从磁盘文件中加载到系统中。
  • 第三步最简单,只需要使用 include / require 即可。要实现第一步,第二步的功能,必须在开发时约定类名与磁盘文件的映射方法,只有这样我们才能根据类名找到它对应的磁盘文件。
  • 当有大量的类文件要包含的时候,我们只要确定相应的规则,然后在 __autoload() 函数中,将类名与实际的磁盘文件对应起来,就可以实现 lazy loading 的效果
  • 如果想详细的了解关于 autoload 自动加载的过程,可以查看手册资料:PHP autoload函数说明

__autoload() 函数存在的问题

  • 如果在一个系统的实现中,如果需要使用很多其它的类库,这些类库可能是由不同的开发人员编写的, 其类名与实际的磁盘文件的映射规则不尽相同。这时如果要实现类库文件的自动加载,就必须 在 __autoload() 函数中将所有的映射规则全部实现,这样的话 __autoload() 函数有可能会非常复杂,甚至无法实现。最后可能会导致 __autoload() 函数十分臃肿,这时即便能够实现,也会给将来的维护和系统效率带来很大的负面影响。
  • 那么问题出现在哪里呢?问题出现在 __autoload() 是全局函数只能定义一次 ,不够灵活,所以所有的类名与文件名对应的逻辑规则都要在一个函数里面实现,造成这个函数的臃肿。那么如何来解决这个问题呢?答案就是使用一个 __autoload调用堆栈 ,不同的映射关系写到不同的 __autoload函数 中去,然后统一注册统一管理,这个就是 PHP5 引入的 SPL Autoload

SPL Autoload

  • SPL是 Standard PHP Library(标准PHP库)的缩写。它是 PHP5 引入的一个扩展标准库,包括 spl autoload 相关的函数以及各种数据结构和迭代器的接口或类。spl autoload 相关的函数具体可见 php中spl_autoload
<?php

// __autoload 函数
//
// function __autoload($class) {
//     include 'classes/' . $class . '.class.php';
// }


function my_autoloader($class) {
    include 'classes/' . $class . '.class.php';
}

spl_autoload_register('my_autoloader');


// 定义的 autoload 函数在 class 里

// 静态方法
class MyClass {
  public static function autoload($className) {
    // ...
  }
}

spl_autoload_register(array('MyClass', 'autoload'));

// 非静态方法
class MyClass {
  public function autoload($className) {
    // ...
  }
}

$instance = new MyClass();
spl_autoload_register(array($instance, 'autoload'));

spl_autoload_register() 就是我们上面所说的__autoload调用堆栈,我们可以向这个函数注册多个我们自己的 autoload() 函数,当 PHP 找不到类名时,PHP就会调用这个堆栈,然后去调用自定义的 autoload() 函数,实现自动加载功能。如果我们不向这个函数输入任何参数,那么就会默认注册 spl_autoload() 函数。


二、PSR 规范

与自动加载相关的规范是 PSR4,在说 PSR4 之前先介绍一下 PSR 标准。PSR 标准的发明和推出组织是:PHP-FIG,它的网站是:www.php-fig.org。由几位开源框架的开发者成立于 2009 年,从那开始也选取了很多其他成员进来,虽然不是 “官方” 组织,但也代表了社区中不小的一块。组织的目的在于:以最低程度的限制,来统一各个项目的编码规范,避免各家自行发展的风格阻碍了程序员开发的困扰,于是大伙发明和总结了 PSR,PSR 是 PHP Standards Recommendation 的缩写,截止到目前为止,总共有 14 套 PSR 规范,其中有 7 套PSR规范已通过表决并推出使用,分别是:

PSR-0 自动加载标准(已废弃,一些旧的第三方库还有在使用)

PSR-1 基础编码标准

PSR-2 编码风格向导

PSR-3 日志接口

PSR-4 自动加载的增强版,替换掉了 PSR-0

PSR-6 缓存接口规范

PSR-7 HTTP 消息接口规范

具体详细的规范标准可以查看PHP 标准规范

PSR4 标准

2013 年底,PHP-FIG 推出了第 5 个规范——PSR-4。

PSR-4 规范了如何指定文件路径从而自动加载类定义,同时规范了自动加载文件的位置。

1)一个完整的类名需具有以下结构:

\<命名空间>\<子命名空间>\<类名>

  • 完整的类名必须要有一个顶级命名空间,被称为 "vendor namespace";
  • 完整的类名可以有一个或多个子命名空间;
  • 完整的类名必须有一个最终的类名;
  • 完整的类名中任意一部分中的下滑线都是没有特殊含义的;
  • 完整的类名可以由任意大小写字母组成;
  • 所有类名都必须是大小写敏感的。

2)根据完整的类名载入相应的文件

  • 完整的类名中,去掉最前面的命名空间分隔符,前面连续的一个或多个命名空间和子命名空间,作为「命名空间前缀」,其必须与至少一个「文件基目录」相对应;
  • 紧接命名空间前缀后的子命名空间 必须 与相应的「文件基目录」相匹配,其中的命名空间分隔符将作为目录分隔符。
  • 末尾的类名必须与对应的以 .php 为后缀的文件同名。
  • 自动加载器(autoloader)的实现一定不可抛出异常、一定不可触发任一级别的错误信息以及不应该有返回值。

3) 例子

PSR-4风格

类名:ZendAbc
命名空间前缀:Zend
文件基目录:/usr/includes/Zend/
文件路径:/usr/includes/Zend/Abc.php
类名:SymfonyCoreRequest
命名空间前缀:SymfonyCore
文件基目录:./vendor/Symfony/Core/
文件路径:./vendor/Symfony/Core/Request.php

目录结构

-vendor/
| -vendor_name/
| | -package_name/
| | | -src/
| | | | -ClassName.php       # Vendor_Name\Package_Name\ClassName
| | | -tests/
| | | | -ClassNameTest.php   # Vendor_Name\Package_Name\ClassNameTest

Composer自动加载过程

Composer 做了哪些事情

  • 你有一个项目依赖于若干个库。
  • 其中一些库依赖于其他库。
  • 你声明你所依赖的东西。
  • Composer 会找出哪个版本的包需要安装,并安装它们(将它们下载到你的项目中)。

例如,你正在创建一个项目,需要做一些单元测试。你决定使用 phpunit 。为了将它添加到你的项目中,你所需要做的就是在 composer.json 文件里描述项目的依赖关系。

 {
   "require": {
     "phpunit/phpunit":"~6.0",
   }
 }

然后在 composer require 之后我们只要在项目里面直接 use phpunit 的类即可使用。

执行 composer require 时发生了什么

  • composer 会找到符合 PR4 规范的第三方库的源
  • 将其加载到 vendor 目录下
  • 初始化顶级域名的映射并写入到指定的文件里

(如:'PHPUnit\\Framework\\Assert' => __DIR__ . '/..' . '/phpunit/phpunit/src/Framework/Assert.php'

  • 写好一个 autoload 函数,并且注册到 spl_autoload_register()里

题外话:现在很多框架都已经帮我们写好了顶级域名映射了,我们只需要在框架里面新建文件,在新建的文件中写好命名空间,就可以在任何地方 use 我们的命名空间了。


Composer 源码分析

下面我们通过对源码的分析来看看 composer 是如何实现 PSR4标准 的自动加载功能。

很多框架在初始化的时候都会引入 composer 来协助自动加载的,以 Laravel 为例,它入口文件 index.php 第一句就是利用 composer 来实现自动加载功能。

启动

<?php
  define('LARAVEL_START', microtime(true));

  require __DIR__ . '/../vendor/autoload.php';

去 vendor 目录下的 autoload.php

<?php
  require_once __DIR__ . '/composer' . '/autoload_real.php';

  return ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29::getLoader();

这里就是 Composer 真正开始的地方了

Composer自动加载文件

首先,我们先大致了解一下Composer自动加载所用到的源文件。

  1. autoload_real.php: 自动加载功能的引导类。

    • composer 加载类的初始化(顶级命名空间与文件路径映射初始化)和注册(spl_autoload_register())。
  2. ClassLoader.php : composer 加载类。

    • composer 自动加载功能的核心类。
  3. autoload_static.php : 顶级命名空间初始化类,

    • 用于给核心类初始化顶级命名空间。
  4. autoload_classmap.php : 自动加载的最简单形式,

    • 有完整的命名空间和文件目录的映射;
  5. autoload_files.php : 用于加载全局函数的文件,

    • 存放各个全局函数所在的文件路径名;
  6. autoload_namespaces.php : 符合 PSR0 标准的自动加载文件,

    • 存放着顶级命名空间与文件的映射;
  7. autoload_psr4.php : 符合 PSR4 标准的自动加载文件,

    • 存放着顶级命名空间与文件的映射;

autoload_real 引导类


在 vendor 目录下的 autoload.php 文件中我们可以看出,程序主要调用了引导类的静态方法 getLoader() ,我们接着看看这个函数。

<?php
    public static function getLoader()
    {
      if (null !== self::$loader) {
          return self::$loader;
      }

      spl_autoload_register(
        array('ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader'), true, true
      );

      self::$loader = $loader = new \Composer\Autoload\ClassLoader();

      spl_autoload_unregister(
        array('ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader')
      );

      $useStaticLoader = PHP_VERSION_ID >= 50600 && !defined('HHVM_VERSION');

      if ($useStaticLoader) {
          require_once __DIR__ . '/autoload_static.php';

          call_user_func(
          \Composer\Autoload\ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::getInitializer($loader)
          );

      } else {
          $map = require __DIR__ . '/autoload_namespaces.php';
          foreach ($map as $namespace => $path) {
              $loader->set($namespace, $path);
          }

          $map = require __DIR__ . '/autoload_psr4.php';
          foreach ($map as $namespace => $path) {
              $loader->setPsr4($namespace, $path);
          }

          $classMap = require __DIR__ . '/autoload_classmap.php';
          if ($classMap) {
              $loader->addClassMap($classMap);
          }
      }

      /***********************注册自动加载核心类对象********************/
      $loader->register(true);

      /***********************自动加载全局函数********************/
      if ($useStaticLoader) {
          $includeFiles = Composer\Autoload\ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$files;
      } else {
          $includeFiles = require __DIR__ . '/autoload_files.php';
      }

      foreach ($includeFiles as $fileIdentifier => $file) {
          composerRequire7b790917ce8899df9af8ed53631a1c29($fileIdentifier, $file);
      }

      return $loader;
    }

我把自动加载引导类分为 5 个部分。

第一部分——单例

第一部分很简单,就是个最经典的单例模式,自动加载类只能有一个。

<?php
  if (null !== self::$loader) {
      return self::$loader;
  }

第二部分——构造ClassLoader核心类

第二部分 new 一个自动加载的核心类对象。

<?php
  /***********************获得自动加载核心类对象********************/
  spl_autoload_register(
    array('ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader'), true, true
  );

  self::$loader = $loader = new \Composer\Autoload\ClassLoader();

  spl_autoload_unregister(
    array('ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader')
  );

loadClassLoader()函数:

<?php
public static function loadClassLoader($class)
{
    if ('Composer\Autoload\ClassLoader' === $class) {
        require __DIR__ . '/ClassLoader.php';
    }
}

从程序里面我们可以看出,composer 先向 PHP 自动加载机制注册了一个函数,这个函数 require 了 ClassLoader 文件。成功 new 出该文件中核心类 ClassLoader() 后,又销毁了该函数。

第三部分 —— 初始化核心类对象

<?php
  /***********************初始化自动加载核心类对象********************/
  $useStaticLoader = PHP_VERSION_ID >= 50600 && !defined('HHVM_VERSION');
  if ($useStaticLoader) {
     require_once __DIR__ . '/autoload_static.php';

     call_user_func(
       \Composer\Autoload\ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::getInitializer($loader)
     );
  } else {
      $map = require __DIR__ . '/autoload_namespaces.php';
      foreach ($map as $namespace => $path) {
         $loader->set($namespace, $path);
      }

      $map = require __DIR__ . '/autoload_psr4.php';
      foreach ($map as $namespace => $path) {
         $loader->setPsr4($namespace, $path);
      }

      $classMap = require __DIR__ . '/autoload_classmap.php';
      if ($classMap) {
          $loader->addClassMap($classMap);
      }
    }
    

这一部分就是对自动加载类的初始化,主要是给自动加载核心类初始化顶级命名空间映射。

初始化的方法有两种:

  1. 使用 autoload_static 进行静态初始化;
  2. 调用核心类接口初始化。

autoload_static 静态初始化 ( PHP >= 5.6 )

静态初始化只支持 PHP5.6 以上版本并且不支持 HHVM 虚拟机。我们深入 autoload_static.php 这个文件发现这个文件定义了一个用于静态初始化的类,名字叫 ComposerStaticInit7b790917ce8899df9af8ed53631a1c29,仍然为了避免冲突而加了 hash 值。这个类很简单:

<?php
  class ComposerStaticInit7b790917ce8899df9af8ed53631a1c29{
     public static $files = array(...);
     public static $prefixLengthsPsr4 = array(...);
     public static $prefixDirsPsr4 = array(...);
     public static $prefixesPsr0 = array(...);
     public static $classMap = array (...);

    public static function getInitializer(ClassLoader $loader)
    {
      return \Closure::bind(function () use ($loader) {
          $loader->prefixLengthsPsr4
                          = ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$prefixLengthsPsr4;

          $loader->prefixDirsPsr4
                          = ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$prefixDirsPsr4;

          $loader->prefixesPsr0
                          = ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$prefixesPsr0;

          $loader->classMap
                          = ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$classMap;

      }, null, ClassLoader::class);
  }

这个静态初始化类的核心就是 getInitializer() 函数,它将自己类中的顶级命名空间映射给了 ClassLoader 类。值得注意的是这个函数返回的是一个匿名函数,为什么呢?原因就是 ClassLoader类 中的 prefixLengthsPsr4prefixDirsPsr4等等变量都是 private的。利用匿名函数的绑定功能就可以将这些 private 变量赋给 ClassLoader 类 里的成员变量。

关于匿名函数的绑定功能

接下来就是命名空间初始化的关键了。

classMap(命名空间映射)

<?php
  public static $classMap = array (
      'App\\Console\\Kernel'
              => __DIR__ . '/../..' . '/app/Console/Kernel.php',

      'App\\Exceptions\\Handler'
              => __DIR__ . '/../..' . '/app/Exceptions/Handler.php',

      'App\\Http\\Controllers\\Auth\\ForgotPasswordController'
              => __DIR__ . '/../..' . '/app/Http/Controllers/Auth/ForgotPasswordController.php',

      'App\\Http\\Controllers\\Auth\\LoginController'
              => __DIR__ . '/../..' . '/app/Http/Controllers/Auth/LoginController.php',

      'App\\Http\\Controllers\\Auth\\RegisterController'
              => __DIR__ . '/../..' . '/app/Http/Controllers/Auth/RegisterController.php',
  ...)

直接命名空间全名与目录的映射,简单粗暴,也导致这个数组相当的大。

PSR4 标准顶级命名空间映射数组:

<?php
  public static $prefixLengthsPsr4 = array(
      'p' => array (
        'phpDocumentor\\Reflection\\' => 25,
    ),
      'S' => array (
        'Symfony\\Polyfill\\Mbstring\\' => 26,
        'Symfony\\Component\\Yaml\\' => 23,
        'Symfony\\Component\\VarDumper\\' => 28,
        ...
    ),
  ...);

  public static $prefixDirsPsr4 = array (
      'phpDocumentor\\Reflection\\' => array (
        0 => __DIR__ . '/..' . '/phpdocumentor/reflection-common/src',
        1 => __DIR__ . '/..' . '/phpdocumentor/type-resolver/src',
        2 => __DIR__ . '/..' . '/phpdocumentor/reflection-docblock/src',
    ),
       'Symfony\\Polyfill\\Mbstring\\' => array (
        0 => __DIR__ . '/..' . '/symfony/polyfill-mbstring',
    ),
      'Symfony\\Component\\Yaml\\' => array (
        0 => __DIR__ . '/..' . '/symfony/yaml',
    ),
  ...)

PSR4 标准顶级命名空间映射用了两个数组,第一个是用命名空间第一个字母作为前缀索引,然后是 顶级命名空间,但是最终并不是文件路径,而是 顶级命名空间的长度。为什么呢?

因为 PSR4 标准是用顶级命名空间目录替换顶级命名空间,所以获得顶级命名空间的长度很重要。

具体说明这些数组的作用:

假如我们找 Symfony\Polyfill\Mbstring\example 这个命名空间,通过前缀索引和字符串匹配我们得到了

<?php
    'Symfony\\Polyfill\\Mbstring\\' => 26,

这条记录,键是顶级命名空间,值是命名空间的长度。拿到顶级命名空间后去 $prefixDirsPsr4数组 获取它的映射目录数组:(注意映射目录可能不止一条)

<?php
  'Symfony\\Polyfill\\Mbstring\\' => array (
              0 => __DIR__ . '/..' . '/symfony/polyfill-mbstring',
          )

然后我们就可以将命名空间 Symfony\\Polyfill\\Mbstring\\example 前26个字符替换成目录 __DIR__ . '/..' . '/symfony/polyfill-mbstring ,我们就得到了__DIR__ . '/..' . '/symfony/polyfill-mbstring/example.php,先验证磁盘上这个文件是否存在,如果不存在接着遍历。如果遍历后没有找到,则加载失败。

ClassLoader 接口初始化( PHP < 5.6 )


如果PHP版本低于 5.6 或者使用 HHVM 虚拟机环境,那么就要使用核心类的接口进行初始化。

<?php
    // PSR0 标准
    $map = require __DIR__ . '/autoload_namespaces.php';
    foreach ($map as $namespace => $path) {
       $loader->set($namespace, $path);
    }

    // PSR4 标准
    $map = require __DIR__ . '/autoload_psr4.php';
    foreach ($map as $namespace => $path) {
       $loader->setPsr4($namespace, $path);
    }

    $classMap = require __DIR__ . '/autoload_classmap.php';
    if ($classMap) {
       $loader->addClassMap($classMap);
    }

PSR4 标准的映射

autoload_psr4.php 的顶级命名空间映射

<?php
    return array(
    'XdgBaseDir\\'
        => array($vendorDir . '/dnoegel/php-xdg-base-dir/src'),

    'Webmozart\\Assert\\'
        => array($vendorDir . '/webmozart/assert/src'),

    'TijsVerkoyen\\CssToInlineStyles\\'
        => array($vendorDir . '/tijsverkoyen/css-to-inline-styles/src'),

    'Tests\\'
        => array($baseDir . '/tests'),

    'Symfony\\Polyfill\\Mbstring\\'
        => array($vendorDir . '/symfony/polyfill-mbstring'),
    ...
    )

PSR4 标准的初始化接口:

<?php
    public function setPsr4($prefix, $paths)
    {
        if (!$prefix) {
            $this->fallbackDirsPsr4 = (array) $paths;
        } else {
            $length = strlen($prefix);
            if ('\\' !== $prefix[$length - 1]) {
                throw new \InvalidArgumentException(
                  "A non-empty PSR-4 prefix must end with a namespace separator."
                );
            }
            $this->prefixLengthsPsr4[$prefix[0]][$prefix] = $length;
            $this->prefixDirsPsr4[$prefix] = (array) $paths;
        }
    }

总结下上面的顶级命名空间映射过程:

( 前缀 -> 顶级命名空间,顶级命名空间 -> 顶级命名空间长度 )
( 顶级命名空间 -> 目录 )

这两个映射数组。具体形式也可以查看下面的 autoload_static 的 $prefixLengthsPsr4 、 $prefixDirsPsr4 。

命名空间映射

autoload_classmap:

<?php
public static $classMap = array (
    'App\\Console\\Kernel'
        => __DIR__ . '/../..' . '/app/Console/Kernel.php',

    'App\\Exceptions\\Handler'
        => __DIR__ . '/../..' . '/app/Exceptions/Handler.php',
    ...
)

addClassMap:

<?php
    public function addClassMap(array $classMap)
    {
        if ($this->classMap) {
            $this->classMap = array_merge($this->classMap, $classMap);
        } else {
            $this->classMap = $classMap;
        }
    }

自动加载核心类 ClassLoader 的静态初始化到这里就完成了!

其实说是5部分,真正重要的就两部分——初始化与注册。初始化负责顶层命名空间的目录映射,注册负责实现顶层以下的命名空间映射规则。

第四部分 —— 注册


讲完了 Composer 自动加载功能的启动与初始化,经过启动与初始化,自动加载核心类对象已经获得了顶级命名空间与相应目录的映射,也就是说,如果有命名空间 'App\Console\Kernel,我们已经可以找到它对应的类文件所在位置。那么,它是什么时候被触发去找的呢?

这就是 composer 自动加载的核心了,我们先回顾一下自动加载引导类:

 public static function getLoader()
 {
    /***************************经典单例模式********************/
    if (null !== self::$loader) {
        return self::$loader;
    }
    
    /***********************获得自动加载核心类对象********************/
    spl_autoload_register(array('ComposerAutoloaderInit
    7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader'), true, true);
    
    self::$loader = $loader = new \Composer\Autoload\ClassLoader();
    
    spl_autoload_unregister(array('ComposerAutoloaderInit
    7b790917ce8899df9af8ed53631a1c29', 'loadClassLoader'));

    /***********************初始化自动加载核心类对象********************/
    $useStaticLoader = PHP_VERSION_ID >= 50600 && 
    !defined('HHVM_VERSION');
    
    if ($useStaticLoader) {
        require_once __DIR__ . '/autoload_static.php';

        call_user_func(\Composer\Autoload\ComposerStaticInit
        7b790917ce8899df9af8ed53631a1c29::getInitializer($loader));
  
    } else {
        $map = require __DIR__ . '/autoload_namespaces.php';
        foreach ($map as $namespace => $path) {
            $loader->set($namespace, $path);
        }

        $map = require __DIR__ . '/autoload_psr4.php';
        foreach ($map as $namespace => $path) {
            $loader->setPsr4($namespace, $path);
        }

        $classMap = require __DIR__ . '/autoload_classmap.php';
        if ($classMap) {
            $loader->addClassMap($classMap);
        }
    }

    /***********************注册自动加载核心类对象********************/
    $loader->register(true);

    /***********************自动加载全局函数********************/
    if ($useStaticLoader) {
        $includeFiles = Composer\Autoload\ComposerStaticInit
        7b790917ce8899df9af8ed53631a1c29::$files;
    } else {
        $includeFiles = require __DIR__ . '/autoload_files.php';
    }
    
    foreach ($includeFiles as $fileIdentifier => $file) {
        composerRequire
        7b790917ce8899df9af8ed53631a1c29($fileIdentifier, $file);
    }

    return $loader;
} 

现在我们开始引导类的第四部分:注册自动加载核心类对象。我们来看看核心类的 register() 函数:

public function register($prepend = false)
{
    spl_autoload_register(array($this, 'loadClass'), true, $prepend);
}

其实奥秘都在自动加载核心类 ClassLoader 的 loadClass() 函数上:

public function loadClass($class)
    {
        if ($file = $this->findFile($class)) {
            includeFile($file);

            return true;
        }
    }

这个函数负责按照 PSR 标准将顶层命名空间以下的内容转为对应的目录,也就是上面所说的将 'App\Console\Kernel 中' Console\Kernel 这一段转为目录,至于怎么转的在下面 “运行”的部分讲。核心类 ClassLoader 将 loadClass() 函数注册到PHP SPL中的 spl_autoload_register() 里面去。这样,每当PHP遇到一个不认识的命名空间的时候,PHP会自动调用注册到 spl_autoload_register 里面的 loadClass() 函数,然后找到命名空间对应的文件。

全局函数的自动加载

Composer 不止可以自动加载命名空间,还可以加载全局函数。怎么实现的呢?把全局函数写到特定的文件里面去,在程序运行前挨个 require就行了。这个就是 composer 自动加载的第五步,加载全局函数。

if ($useStaticLoader) {
    $includeFiles = Composer\Autoload\ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$files;
} else {
    $includeFiles = require __DIR__ . '/autoload_files.php';
}
foreach ($includeFiles as $fileIdentifier => $file) {
    composerRequire7b790917ce8899df9af8ed53631a1c29($fileIdentifier, $file);
}

跟核心类的初始化一样,全局函数自动加载也分为两种:静态初始化和普通初始化,静态加载只支持PHP5.6以上并且不支持HHVM。

静态初始化:

ComposerStaticInit7b790917ce8899df9af8ed53631a1c29::$files:

public static $files = array (
'0e6d7bf4a5811bfa5cf40c5ccd6fae6a' => __DIR__ . '/..' . '/symfony/polyfill-mbstring/bootstrap.php',
'667aeda72477189d0494fecd327c3641' => __DIR__ . '/..' . '/symfony/var-dumper/Resources/functions/dump.php',
...
);

普通初始化

autoload_files:

$vendorDir = dirname(dirname(__FILE__));
$baseDir = dirname($vendorDir);
    
return array(
'0e6d7bf4a5811bfa5cf40c5ccd6fae6a' => $vendorDir . '/symfony/polyfill-mbstring/bootstrap.php',
'667aeda72477189d0494fecd327c3641' => $vendorDir . '/symfony/var-dumper/Resources/functions/dump.php',
   ....
);

其实跟静态初始化区别不大。

加载全局函数

class ComposerAutoloaderInit7b790917ce8899df9af8ed53631a1c29{
  public static function getLoader(){
      ...
      foreach ($includeFiles as $fileIdentifier => $file) {
        composerRequire7b790917ce8899df9af8ed53631a1c29($fileIdentifier, $file);
      }
      ...
  }
}

function composerRequire7b790917ce8899df9af8ed53631a1c29($fileIdentifier, $file)
 {
    if (empty(\$GLOBALS['__composer_autoload_files'][\$fileIdentifier])) {
        require $file;

        $GLOBALS['__composer_autoload_files'][$fileIdentifier] = true;
    }
}

第五部分 —— 运行

到这里,终于来到了核心的核心—— composer 自动加载的真相,命名空间如何通过 composer 转为对应目录文件的奥秘就在这一章。
前面说过,ClassLoader 的 register() 函数将 loadClass() 函数注册到 PHP 的 SPL 函数堆栈中,每当 PHP 遇到不认识的命名空间时就会调用函数堆栈的每个函数,直到加载命名空间成功。所以 loadClass() 函数就是自动加载的关键了。

看下 loadClass() 函数:

public function loadClass($class)
{
    if ($file = $this->findFile($class)) {
        includeFile($file);

        return true;
    }
}

public function findFile($class)
{
    // work around for PHP 5.3.0 - 5.3.2 https://bugs.php.net/50731
    if ('\\' == $class[0]) {
        $class = substr($class, 1);
    }

    // class map lookup
    if (isset($this->classMap[$class])) {
        return $this->classMap[$class];
    }
    if ($this->classMapAuthoritative) {
        return false;
    }

    $file = $this->findFileWithExtension($class, '.php');

    // Search for Hack files if we are running on HHVM
    if ($file === null && defined('HHVM_VERSION')) {
        $file = $this->findFileWithExtension($class, '.hh');
    }

    if ($file === null) {
        // Remember that this class does not exist.
        return $this->classMap[$class] = false;
    }

    return $file;
}

我们看到 loadClass() ,主要调用 findFile() 函数。findFile() 在解析命名空间的时候主要分为两部分:classMap 和 findFileWithExtension() 函数。classMap 很简单,直接看命名空间是否在映射数组中即可。麻烦的是 findFileWithExtension() 函数,这个函数包含了 PSR0 和 PSR4 标准的实现。还有个值得我们注意的是查找路径成功后 includeFile() 仍然是外面的函数,并不是 ClassLoader 的成员函数,原理跟上面一样,防止有用户写 $this 或 self。还有就是如果命名空间是以\开头的,要去掉\然后再匹配。

看下 findFileWithExtension 函数:

private function findFileWithExtension($class, $ext)
{
    // PSR-4 lookup
    $logicalPathPsr4 = strtr($class, '\\', DIRECTORY_SEPARATOR) . $ext;
    
    $first = $class[0];
    if (isset($this->prefixLengthsPsr4[$first])) {
        foreach ($this->prefixLengthsPsr4[$first] as $prefix => $length) {
            if (0 === strpos($class, $prefix)) {
                foreach ($this->prefixDirsPsr4[$prefix] as $dir) {
                    if (file_exists($file = $dir . DIRECTORY_SEPARATOR . substr($logicalPathPsr4, $length))) {
                        return $file;
                    }
                }
            }
        }
    }

    // PSR-4 fallback dirs
    foreach ($this->fallbackDirsPsr4 as $dir) {
        if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr4)) {
            return $file;
        }
    }
    
    // PSR-0 lookup
    if (false !== $pos = strrpos($class, '\\')) {
        // namespaced class name
        $logicalPathPsr0 = substr($logicalPathPsr4, 0, $pos + 1)
            . strtr(substr($logicalPathPsr4, $pos + 1), '_', DIRECTORY_SEPARATOR);
    } else {
        // PEAR-like class name
        $logicalPathPsr0 = strtr($class, '_', DIRECTORY_SEPARATOR) . $ext;
    }
    
    if (isset($this->prefixesPsr0[$first])) {
        foreach ($this->prefixesPsr0[$first] as $prefix => $dirs) {
            if (0 === strpos($class, $prefix)) {
                foreach ($dirs as $dir) {
                    if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr0)) {
                        return $file;
                    }
                }
            }
        }
    }
    
    // PSR-0 fallback dirs
    foreach ($this->fallbackDirsPsr0 as $dir) {
        if (file_exists($file = $dir . DIRECTORY_SEPARATOR . $logicalPathPsr0)) {
            return $file;
        }
    }
    
    // PSR-0 include paths.
    if ($this->useIncludePath && $file = stream_resolve_include_path($logicalPathPsr0)) {
        return $file;
    }
}

最后小结

我们通过举例来说下上面代码的流程:

如果我们在代码中写下 new phpDocumentor\Reflection\Element(),PHP 会通过 SPL_autoload_register 调用 loadClass -> findFile -> findFileWithExtension。步骤如下:

  • 将 \ 转为文件分隔符/,加上后缀php,变成 $logicalPathPsr4, 即 phpDocumentor/Reflection//Element.php;
  • 利用命名空间第一个字母p作为前缀索引搜索 prefixLengthsPsr4 数组,查到下面这个数组:
        p' => 
            array (
                'phpDocumentor\\Reflection\\' => 25,
                'phpDocumentor\\Fake\\' => 19,
          )
  • 遍历这个数组,得到两个顶层命名空间 phpDocumentor\Reflection\ 和 phpDocumentor\Fake\
  • 在这个数组中查找 phpDocumentor\Reflection\Element,找出 phpDocumentor\Reflection\ 这个顶层命名空间并且长度为25。
  • 在prefixDirsPsr4 映射数组中得到phpDocumentor\Reflection\ 的目录映射为:
    'phpDocumentor\\Reflection\\' => 
        array (
            0 => __DIR__ . '/..' . '/phpdocumentor/reflection-common/src',
            1 => __DIR__ . '/..' . '/phpdocumentor/type-resolver/src',
            2 => __DIR__ . '/..' . '/phpdocumentor/reflection-docblock/src',
        ),
  • 遍历这个映射数组,得到三个目录映射;
  • 查看 “目录+文件分隔符//+substr(&dollar;logicalPathPsr4, &dollar;length)”文件是否存在,存在即返回。这里就是
    '__DIR__/../phpdocumentor/reflection-common/src + substr(phpDocumentor/Reflection/Element.php,25)'
  • 如果失败,则利用 fallbackDirsPsr4 数组里面的目录继续判断是否存在文件

以上就是 composer 自动加载的原理解析!

The end . Thanks!

更多好文,关注公众号获取

file

查看原文

arunfung 收藏了文章 · 2019-10-08

Laravel 服务容器必知必会

文章转发自专业的Laravel开发者社区,原始链接:https://learnku.com/laravel/t...

学习如何用 Laravel 构建一个应用程序,不仅仅是学习使用不同的类和框架中的组件,也不是要记住全部的 artisan 命令或所有的辅助函数(我们有 Google)。学习用 Laravel 编码是学习它的哲学和优雅迷人的语法。 我个人觉得是一件艺术和工艺品(巧合的是 Laravel 工程师有时也被称作 Web 艺术家)。对其他框架这也是真理。

服务容器和 IOC 容器是 Laravel 哲学的主要部分。作为一个 Laravel 开发者,理解并能正确的使用服务容器是你掌握它的重要部分, 因为它是任何 Laravel 应用的核心。

基础

虽然 IOC 容器本质上只是一个普通的 PHP 类, 但是我喜欢将它看做"袋中的技巧"。 这个"袋子"就是我们放置或者"绑定"任何我们需要运行在 Laravel 应用中的对象服务, 从接口实现到目录路径以及其他等等。因此叫做"袋中的技巧"

现在我们拥有了一个包含所有绑定对象服务的单一对象( IOC 容器), 因此在我们的代码中,任何时候都可以很容易的从这个单一对象中获取或者"解析"这些对象服务

绑定的处理方式

现在假设我们有一个特别功能的 FooService 类。

<?php
namespace App\Services;
class FooService
{
    public function __construct()
    {
        ...
    }
    public function doSomething()
    {
        // Code for Something.
    }
}

如果我们要调用类的 doSomething 方法,我们可能会这样做 :

$fooService = new \App\Services\FooService();\
$fooService->doSomething();

这看起来没有什么问题,但比较麻烦的是这儿的 'new' 关键字,我的意思是虽然这样也很好,但是我们可以做的更优雅 (记住写代码要像 Laravel 一样,用优雅的方式)。

如何绑定 ?

绑定简单得可以用一行代码完成

$this->app->bind('FooService', \App\Services\FooService::class);

在 Laravel 中我们常说:“把 FooService 服务巧妙的注入到包中”。

当然根据使用场景和服务方式,也有其他的方法来绑定服务,只要你理解它的基本思想。有关绑定的完整参考,可以查阅 Laravel 的文档 服务容器

需要注意的是,服务必须绑定到服务提供商的注册方法中。

如何解析 ?

当服务绑定到容器之后, 我们可以在应用中的任何地方获取或者解析服务.

// 使用IoC 我们可以这么做
$fooService = app()->make('FooService');
$fooService->doSomething();
// 也可以精简为一行代码
app()->make('FooService')->doSomething();

我们只需要告诉 Laravel : "记住 FooService, 当我需要时把它给我." 你注意到了吗? 用 IoC 创建服务让代码更简洁, 明了, 易读. 这就是 Laravel 的优雅之处, 并且会使你的代码更易于测试, 因为当你测试时你可以使用一个伪造的类去替换 FooService (我觉得你应该很熟悉怎么在测试中伪造类).

在容器中绑定接口

在面向对象编程中,接口是创建一些必须遵循某种规划或者约束的类的一种方法。这能帮助其他开发者创建与您的接口中设置的约束相匹配的代码。这强制他们传递合法的参数给函数并且返回特定的数据类型,尽管他们的方法的实现可能有所不同。通过这种方式,您可以轻松的确定继承相同接口的不同实现将以相同的方式工作。

在 Laravel 的容器中我们能够绑定一个特定的接口的实现,通过这种方式,当我们解析这个接口时,我们最终会得到绑定到它的具体类。

$this->app->bind(FooInterface::class, FooClass::class);

因此,当 FooInterface 被成功解析,Laravel 足够聪明的给我们一个 FooClass 的实例。

现在想象一下我们已经写了一个 FooInterface 的更好的实现叫做 BarClass,并且我们希望用它替换 FooClass,我们所需要做的所有事情就是:

$this->app->bind(FooInterface::class, BarClass::class);

我们的代码依旧正常运行因为我们知道 BarClass 会遵循我们的接口,就算 BarClass 和预期的表现不一致我们也可以切换回 FooClass 。这是一种很好的方法,能在没有太多回归(regressions)的情况下升级应用的代码。

依赖解析

我们知道 Laravel 能够解析我们在容器中绑定的服务和接口,但是它能做的不仅仅是这些。事实上,它还能在我们一行代码都不写的情况下自动为我们解析这些服务的依赖。

想象一下我们的项目中有下面这些服务类。

<?php
class BarService 
{
  /**
   * 要做的事情。
   * 
   * @return string
   */
  public function somethingToDo()
  {
    return 'I am doing something';
  }
}
<?php
class FooService 
{
  /**
   * BarService 实例.
   * 
   * @var BarService
   */
  protected $bar;
  
  /**
   * 创建新的 FooService 实例
   * 
   * @param BarService $bar
   */
  public function __construct(BarService $bar)
  {
    $this->bar = $bar;
  }
  
  /**
   * 做点有用的事
   * 
   * @return string
   */
  public function doSomething()
  {
    return $this->bar->somethingToDo();
  }
}

我们能看到 FooService 需要一个 BarService 的实例。我们怎么才能把它绑定到容器中这样当 Laravel 给我们一个 FooService 的实例时它也会给我们一个BarService 的实例?

你或许会想这个解决方法可能会是下面这样:

$this->app->bind('Foo', new FooService(new BarService));

从技术上来说,这是可以实现的,但实际上我们不需要这样做。 Laravel 通过使用 PHP 强大的反射特性,自动就为我们解决了这个问题。因此,你只需要像往常那样绑定就好:

$this->app->bind('Foo', FooService::class);

现在,当代码解析到 Foo 时, Laravel 将会去寻找 FooService 服务,当发现它需要一个 BarService 服务的实例; Laravel 又将会去寻找 BarService 服务,并将它实例化之后的对象提供给 FooService 服务的构造函数,从而为我们创建一个完整的实例。这些过程不需要我们写一行代码,真的是十分惊艳而又清晰的思路!!

除此之外,上述过程将会提供给所有的依赖。所以,如果 BarService 服务也有自己的依赖,那么也会通过上述的方式来解决。

最后的话

关于 Laravel 的服务容器还有许多很棒的事情需要讨论和学习。我希望这个小介绍能给你一些启发并帮助你加深对容器的理解。

我鼓励你通过阅读文档了解更多  [docs]
( https://laravel.com/docs/5.6/... )。

感谢你的阅读。

查看原文

arunfung 收藏了文章 · 2019-07-15

基于Laravel的配置管理系统设计

项目背景

硬件架构采用Nginx + SLB,应用程式使用 Laravel.env 进行配置管理 ,随着业务的迭代越来越多的配置被写入 .env 文件,变得越来越臃肿,管理起来也不方便。

按照集群设计,支持分布式扩展,配置中心不可用要保证不影响业务,客户端使用Redis + File的方式保存 配置 信息。
使用 supervisor 守护进程,支持秒级获取配置,后续可扩展为消息订阅

架构图

图片描述

基于composer开发扩展,配置中心客户端通信基于RESTful,系统拆分为2个composer,server 包 + client 包。

server 负责配置管理,client 负责API封装

UI界面

配置管理

图片描述

数组支持用.号,支持键值使用json

接口数据

图片描述

客户端请求接口,最终转被换成PHP数组。

表设计

多应用

CREATE TABLE `tms_configure_client` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `is_active` tinyint(1) NOT NULL DEFAULT '1' COMMENT '状态',
  `app_id` varchar(32) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'APPID',
  `title` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '名称',
  `intro` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '描述',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `configure_client_app_id_index` (`app_id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
给每个应用分配一个APPID是很有必要的。

配置分组

CREATE TABLE `tms_configure_group` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `ip` varchar(30) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT 'ip地址',
  `title` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '标题',
  `intro` varchar(200) COLLATE utf8mb4_unicode_ci NOT NULL COMMENT '描述',
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
暂时仅支持定义到 APPID + IP 级别配置

配置节点

CREATE TABLE `tms_configure_node` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `app_id` bigint(20) unsigned NOT NULL COMMENT 'APPID',
  `is_active` tinyint(3) unsigned NOT NULL DEFAULT '1',
  `version_id` varchar(20) COLLATE utf8mb4_unicode_ci NOT NULL,
  `group_id` bigint(20) unsigned NOT NULL,
  `skey` varchar(50) COLLATE utf8mb4_unicode_ci NOT NULL,
  `svalue` varchar(2000) COLLATE utf8mb4_unicode_ci NOT NULL,
  `remark` varchar(50) COLLATE utf8mb4_unicode_ci DEFAULT NULL,
  `created_at` timestamp NULL DEFAULT NULL,
  `updated_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_acitve` (`is_active`,`group_id`),
  KEY `idx_skey` (`skey`),
  KEY `configure_node_app_id_is_active_group_id_index` (`app_id`,`is_active`,`group_id`)
) ENGINE=InnoDB AUTO_INCREMENT=102 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
这里我们支持 mysql.port 这种采用.key的形式,后面最终转化为php数组。

Composer包

服务端

{
    "name": "xxx/xxx",
    "type": "library",
    "keywords": ["laravel","php","configure"],
    "description": "configure-server module",
    "homepage": "https://github.com/xxx",
    "license": "MIT",
    "authors": [
        {
            "name": "OkamiChen",
            "email": "x25125x@126.com"
        }
    ],
    "require": {
        "php": ">=7.1.0"
    },
    "autoload": {
        "psr-4": {
            "OkamiChen\\ConfigureServer\\":"src/"
        }
    },
    "extra": {
        "laravel": {
            "providers": [
                "OkamiChen\\ConfigureServer\\ServerServiceProvider"
            ]
        }
    }
}

客户端

{
    "name": "xxx/xxx",
    "type": "library",
    "keywords": ["laravel","php","configure"],
    "description": "configure-client module",
    "homepage": "https://github.com/xxx",
    "license": "MIT",
    "authors": [
        {
            "name": "OkamiChen",
            "email": "x25125x@126.com"
        }
    ],
    "require": {
        "php": ">=7.1.0"
    },
    "autoload": {
        "psr-4": {
            "OkamiChen\\ConfigureClient\\":"src/"
        },
        "files": [
            "src/helper.php"
        ]
    },
    "extra": {
        "laravel": {
            "providers": [
                "OkamiChen\\ConfigureClient\\ClientServiceProvider"
            ]
        }
    }
}

结束语

今天先写到这里,后面开始coding工作。

查看原文

arunfung 收藏了文章 · 2019-05-28

RPC vs REST vs GraphQL

写在前面

最近2周的时间由于工作不忙,一直在看有关GraphQL的东西,前后端均有涉及,由于我之前做过后端开发,当时实现的接口的大体是符合RPC风格的接口。后来转做了前端开发,从实现接口者变成了调用接口者,接触最多的当属REST风格的接口。因此在这段学习GraphQL的过程中,并且也尝试使用它以全栈的角度做了一个小项目,在这个过程中,一直在思考它对比前两者在API设计的整体架构体系中的各个指标上,孰优孰劣。

其实在使用和学习的过程中,有很多文章都对比过它们的异同,但是大部分文章并没有从一个相对客观的角度来对比,更多是为了突显一个的优点而刻意指出另外一个的缺点。这让我想到一句话,脱离业务情景谈技术就是耍流氓。

昨天订阅的GraphQL Weekly中推送的一个视频正好是讲关于它们这三者的,于是就点进去看了看,发现质量还是不错的,于是就想整理出来,分享给大家。

原视频地址(油管地址,自备梯子):这里

如果没有梯子的话直接看我整理的东西也可以,我觉的应该都覆盖到视频中所讲的重点内容了。

当然,这些内容如果分开来讲,每一块内容所涉及的东西都够写一本书了,这里仅仅是简单归纳和整理,从宏观的角度来对比它们的异同,从而能够在日后面临技术选型时,有一个更佳明确的决策方向。

RPC

先简单介绍下RPC,它是Remote Procedure Call(远程过程调用)的简称。一般基于RPC协议所设计的接口,是基于网络采用客户端/服务端的模式完成调用接口的。

优点

  • 简单并且易于理解(面向开发者)
  • 轻量级的数据载体
  • 高性能

缺点

  • 对于系统本身耦合性高
  • 因为RPC本身很简单、轻量,因此很容易造成 function explosion

关于RPC的优点其实很好理解,就是因为它性能高同时又很简单,但是我认为这是对于接口提供者来讲的(因为它的高耦合性)。

但是如果从接口调用者的角度来看,高耦合性就变成了缺点,因为高耦合意味着调用者必须要足够了解系统本身的实现才能够完成调用,比如:

  • 调用者需要知道所调用接口的函数名、参数格式、参数顺序、参数名称等等
  • 如果接口提供者(server)要对接口做出一些改变,很容易对接口调用者(client)造成breaking change(违背开闭原则)
  • 一般RPC所暴露接口仅仅会暴露函数的名称和参数等信息,对于函数之间的调用关系无法提供,这意味着调用者必须足够了解系统,从能够知道如何正确的调用这些接口,但是对于接口调用者往往不需要了解过多系统内部实现细节

关于上面的第二点,为了减少breaking change,我之前实现接口的时候一般都会引入版本的概念,就是在暴露接口的方法名中加入版本号,一开始效果确实不错,但是随后就不知不觉的形成了function explosion,和视频中主讲人所举例的例子差不多,贴一下视频中的截图感受一波:

图片描述

REST

当前REST风格的API架构方式已经成了主流解决方案了,相比较RPC,它的主要不同之处在于,它是对于资源(Resource)的模型化而非步骤(Procedure)。

优点

  • 对于系统本身耦合性低,调用者不再需要了解接口内部处理和实现细节
  • 重复使用了一些 http 协议中的已定义好的部分状态动词,增强语义表现力
  • API可以随着时间而不断演进

缺点

  • 缺少约束,缺少简单、统一的规范
  • 有时候 payload 会变的冗余(overload),有时候调用api会比较繁琐(chattiness)
  • 有时候需要发送多条请求已获取数据,在网络带宽较低的场景,往往会造成不好的影响

REST的优点基本解决了RPC中存在的问题,就是解耦,从而使得前后端分离成为可能。接口提供者在修改接口时,不容易造成breaking-change,接口调用者在调用接口时,往往面向数据模型编程,而省去了了解接口本身的时间成本。

但是,我认为REST当前最大的问题在于虽然它利用http的动词约束了接口的暴露方式,同时增强了语义,但是却没有约束接口如何返回数据的最佳实践,总让人感觉只要是返回json格式的接口都可以称作REST。

我在实际工作中,经常会遇到第二条缺点所指出的问题,就是接口返回的数据冗余度很高,但是却缺少我真正需要的数据,因此不得已只能调用其他接口或者直接和后端商议修改接口,并且这种问题会在web端和移动端共用一套接口中被放大。

当前比较好的解决方案就是规范化返回数据的格式,比如json-schema或者自己制定的规范。

GraphQL

GraphQL是近来比较热门的一个技术话题,相比REST和RPC,它汲取了两者的优点,即不面向资源,也不面向过程,而是面向数据查询(ask for exactly what you want)。

同时GraphQL本身需要使用强类型的Schema来对数据模型进行定义,因此相比REST它的约束性更强。

优点

  • 网络开销低,可以在单一请求中获取REST中使用多条请求获取的资源
  • 强类型Schema(约束意味着可以根据规范形成文档、IDE、错误提示等生态工具)
  • 特别适合状数据结构的业务场景(比如好友、流程、组织架构等系统)

缺点

  • 本身的语法相比较REST和RPC均复杂一些
  • 实现方面需要配套 Caching 以解决性能瓶颈
  • 对于 API 的版本控制当前没有完善解决方案(社区的建议是不要使API版本化)
  • 仍然是新鲜事物,很多技术细节仍然处于待验证状态

鉴于GraphQL这两个星期我也仅仅是做了一些简单地使用和了解,仅仅说一下感受。

首先值得肯定的是,在某些程度上确实解决了REST的缺点所带来的问题,同时配套社区建议的各种工具和库,相比使用REST风格,全栈开发体验上升一个台阶。

但是这个看起来很好的东西为什么没有火起来呢?我觉的最主要的原因是因为GraphQL所带来的好处,大部分是对于接口调用者而言的,但是实现这部分的工作却需要接口提供者来完成。

同时GraphQL的最佳实践场景应当是类似像Facebook这样的网站,业务逻辑模型是图状数据结构,比如社交。如果在一些业务逻辑模型相对简单的场景,使用GraphQL确实不如使用REST来得简单明了、直截了当。

另外一方面是GraphQL的使用场景相当灵活,在我自己的调研项目中,我是把它当做一个类似ORM的框架来使用的,在别人的一些文章中,会把它当做一个中间层来做渐进式开发和系统升级。这应当算是另外一个优点。

到底用哪个

下面根据要设计的API类型给予一些技术选型建议。

如果是Management API,这类API的特点如下:

  • 关注于对象与资源
  • 会有多种不同的客户端
  • 需要良好的可发现性和文档

这种情景使用REST + JSON API可能会更好。

如果是Command or Action API,这类API的特点如下:

  • 面向动作或者指令
  • 仅需要简单的交互

这种情况使用RPC就足够了。

如果是Internal Micro Services API,这类API的特点如下:

  • 消息密集型
  • 对系统性能有较高要求

这种情景仍然建议使用RPC

如果是Micro Services API,这类API的特点如下:

  • 消息密集型
  • 期望系统开销较低

这种情景使用RPC或者REST均可。

如果是Data or Mobile API,这类API的特点是:

  • 数据类型是具有图状的特点
  • 希望对于高延迟场景可以有更好的优化

这种场景无疑GraphQL是最好的选择。

写在最后

提供一张表格来总览它们之间在不同指标下的表现:

耦合性约束性复杂度缓存可发现性版本控制
RPC(Function)highmediumlowcustombadhard
REST(Resource)lowlowlowhttpgoodeasy
GraphQL(Query)mediumhighmediumcustomgood???

最后引用人月神话中的观点no silver bullet,在技术选型时需要具体情况具体分析,不过鉴于GraphQL的灵活性,把它与RPC和REST配置使用,也是不错的选择。

查看原文

arunfung 收藏了文章 · 2019-05-28

30分钟理解GraphQL核心概念

写在前面

在上一篇文章RPC vs REST vs GraphQL中,对于这三者的优缺点进行了比较宏观的对比,而且我们也会发现,一般比较简单的项目其实并不需要GraphQL,但是我们仍然需要对新的技术有一定的了解和掌握,在新技术普及时才不会措手不及。

这篇文章主要介绍一些我接触GraphQL的这段时间,觉得需要了解的比较核心的概念,比较适合一下人群:

  • 听说过GraphQL的读者,想深入了解一下
  • 想系统地学习GraphQL的读者
  • 正在调研GraphQL技术的读者

这些概念并不局限于服务端或者是客户端,如果你熟悉这些概念,在接触任意使用GraphQL作为技术背景的库或者框架时,都可以通过文档很快的上手。

如果你已经GraphQL应用于了实际项目中,那么这篇文章可能不适合你,因为其中并没有包含一些实践中的总结和经验,关于实践的东西我会在之后再单另写一篇文章总结。

什么是GraphQL

介绍GraphQL是什么的文章网上一搜一大把,篇幅有长有短,但是从最核心上讲,它是一种查询语言,再进一步说,是一种API查询语言。

这里可能有的人就会说,什么?API还能查?API不是用来调用的吗?是的,这正是GraphQL的强大之处,引用官方文档的一句话:

ask exactly what you want.

我们在使用REST接口时,接口返回的数据格式、数据类型都是后端预先定义好的,如果返回的数据格式并不是调用者所期望的,作为前端的我们可以通过以下两种方式来解决问题:

  • 和后端沟通,改接口(更改数据源)
  • 自己做一些适配工作(处理数据源)

一般如果是个人项目,改后端接口这种事情可以随意搞,但是如果是公司项目,改后端接口往往是一件比较敏感的事情,尤其是对于三端(web、andriod、ios)公用同一套后端接口的情况。大部分情况下,均是按第二种方式来解决问题的。

因此如果接口的返回值,可以通过某种手段,从静态变为动态,即调用者来声明接口返回什么数据,很大程度上可以进一步解耦前后端的关联。

在GraphQL中,我们通过预先定义一张Schema和声明一些Type来达到上面提及的效果,我们需要知道:

  • 对于数据模型的抽象是通过Type来描述的
  • 对于接口获取数据的逻辑是通过Schema来描述的

这么说可能比较抽象,我们一个一个来说明。

Type

对于数据模型的抽象是通过Type来描述的,每一个Type有若干Field组成,每个Field又分别指向某个Type。

GraphQL的Type简单可以分为两种,一种叫做Scalar Type(标量类型),另一种叫做Object Type(对象类型)

Scalar Type

GraphQL中的内建的标量包含,StringIntFloatBooleanEnum,对于熟悉编程语言的人来说,这些都应该很好理解。

值得注意的是,GraphQL中可以通过Scalar声明一个新的标量,比如:

  • prisma(一个使用GraphQL来抽象数据库操作的库)中,还有DateTimeID这两个标量分别代表日期格式和主键
  • 在使用GraphQL实现文件上传接口时,需要声明一个Upload标量来代表要上传的文件

总之,我们只需要记住,标量是GraphQL类型系统中最小的颗粒,关于它在GraphQL解析查询结果时,我们还会再提及它。

Object Type

仅有标量是不够的抽象一些复杂的数据模型的,这时候我们需要使用对象类型,举个例子(先忽略语法,仅从字面上看):

type Article {
  id: ID
  text: String
  isPublished: Boolean
}

上面的代码,就声明了一个Article类型,它有3个Field,分别是ID类型的id,String类型的text和Boolean类型的isPublished。

对于对象类型的Field的声明,我们一般使用标量,但是我们也可以使用另外一个对象类型,比如如果我们再声明一个新的User类型,如下:

type User {
  id: ID
  name: String
}

这时我们就可以稍微的更改一下关于Article类型的声明代码,如下:

type Article {
  id: ID
  text: String
  isPublished: Boolean
  author: User
}

Article新增的author的Field是User类型, 代表这篇文章的作者。

总之,我们通过对象模型来构建GraphQL中关于一个数据模型的形状,同时还可以声明各个模型之间的内在关联(一对多、一对一或多对多)。

Type Modifier

关于类型,还有一个较重要的概念,即类型修饰符,当前的类型修饰符有两种,分别是ListRequired ,它们的语法分别为[Type]Type!, 同时这两者可以互相组合,比如[Type]!或者[Type!]或者[Type!]!(请仔细看这里!的位置),它们的含义分别为:

  • 列表本身为必填项,但其内部元素可以为空
  • 列表本身可以为空,但是其内部元素为必填
  • 列表本身和内部元素均为必填

我们进一步来更改上面的例子,假如我们又声明了一个新的Comment类型,如下:

type Comment {
  id: ID!
  desc: String,
  author: User!
}

你会发现这里的ID有一个!,它代表这个Field是必填的,再来更新Article对象,如下:

type Article {
  id: ID!
  text: String
  isPublished: Boolean
  author: User!
  comments: [Comment!]
}

我们这里的作出的更改如下:

  • id字段改为必填
  • author字段改为必填
  • 新增了comments字段,它的类型是一个元素为Comment类型的List类型

最终的Article类型,就是GraphQL中关于文章这个数据模型,一个比较简单的类型声明。

Schema

现在我们开始介绍Schema,我们之前简单描述了它的作用,即它是用来描述对于接口获取数据逻辑的,但这样描述仍然是有些抽象的,我们其实不妨把它当做REST架构中每个独立资源的uri来理解它,只不过在GraphQL中,我们用Query来描述资源的获取方式。因此,我们可以将Schema理解为多个Query组成的一张表。

这里又涉及一个新的概念Query,GraphQL中使用Query来抽象数据的查询逻辑,当前标准下,有三种查询类型,分别是query(查询)mutation(更改)subscription(订阅)

Note: 为了方便区分,Query特指GraphQL中的查询(包含三种类型),query指GraphQL中的查询类型(仅指查询类型)

Query

上面所提及的3中基本查询类型是作为Root Query(根查询)存在的,对于传统的CRUD项目,我们只需要前两种类型就足够了,第三种是针对当前日趋流行的real-time应用提出的。

我们按照字面意思来理解它们就好,如下:

  • query(查询):当获取数据时,应当选取Query类型
  • mutation(更改):当尝试修改数据时,应当使用mutation类型
  • subscription(订阅):当希望数据更改时,可以进行消息推送,使用subscription类型

仍然以一个例子来说明。

首先,我们分别以REST和GraphQL的角度,以Article为数据模型,编写一系列CRUD的接口,如下:

Rest 接口

GET /api/v1/articles/
GET /api/v1/article/:id/
POST /api/v1/article/
DELETE /api/v1/article/:id/
PATCH /api/v1/article/:id/

GraphQL Query

query {
  articles(): [Article!]!
  article(id: Int): Article!
}

mutation {
  createArticle(): Article!
  updateArticle(id: Int): Article!
  deleteArticle(id: Int): Article!
}

对比我们较熟悉的REST的接口我们可以发现,GraphQL中是按根查询的类型来划分Query职能的,同时还会明确的声明每个Query所返回的数据类型,这里的关于类型的语法和上一章节中是一样的。需要注意的是,我们所声明的任何Query都必须是Root Query的子集,这和GraphQL内部的运行机制有关。

例子中我们仅仅声明了Query类型和Mutation类型,如果我们的应用中对于评论列表有real-time的需求的话,在REST中,我们可能会直接通过长连接或者通过提供一些带验证的获取长连接url的接口,比如:

POST /api/v1/messages/

之后长连接会将新的数据推送给我们,在GraphQL中,我们则会以更加声明式的方式进行声明,如下

subscription {
  updatedArticle() {
    mutation
    node {
        comments: [Comment!]!
    }
  }
}

我们不必纠结于这里的语法,因为这篇文章的目的不是让你在30分钟内学会GraphQL的语法,而是理解的它的一些核心概念,比如这里,我们就声明了一个订阅Query,这个Query会在有新的Article被创建或者更新时,推送新的数据对象。当然,在实际运行中,其内部实现仍然是建立于长连接之上的,但是我们能够以更加声明式的方式来进行声明它。

Resolver

如果我们仅仅在Schema中声明了若干Query,那么我们只进行了一半的工作,因为我们并没有提供相关Query所返回数据的逻辑。为了能够使GraphQL正常工作,我们还需要再了解一个核心概念,Resolver(解析函数)

GraphQL中,我们会有这样一个约定,Query和与之对应的Resolver是同名的,这样在GraphQL才能把它们对应起来,举个例子,比如关于articles(): [Article!]!这个Query, 它的Resolver的名字必然叫做articles

在介绍Resolver之前,是时候从整体上了解下GraphQL的内部工作机制了,假设现在我们要对使用我们已经声明的articles的Query,我们可能会写以下查询语句(同样暂时忽略语法):

Query {
  articles {
       id
       author {
           name
       }
       comments {
      id
      desc
      author
    }
  }
}

GraphQL在解析这段查询语句时会按如下步骤(简略版):

  • 首先进行第一层解析,当前QueryRoot Query类型是query,同时需要它的名字是articles
  • 之后会尝试使用articlesResolver获取解析数据,第一层解析完毕
  • 之后对第一层解析的返回值,进行第二层解析,当前articles还包含三个子Query,分别是idauthorcomments

    • id在Author类型中为标量类型,解析结束
    • author在Author类型中为对象类型User,尝试使用UserResolver获取数据,当前field解析完毕
    • 之后对第二层解析的返回值,进行第三层解析,当前author还包含一个Query, name,由于它是标量类型,解析结束
    • comments同上...

我们可以发现,GraphQL大体的解析流程就是遇到一个Query之后,尝试使用它的Resolver取值,之后再对返回值进行解析,这个过程是递归的,直到所解析Field的类型是Scalar Type(标量类型)为止。解析的整个过程我们可以把它想象成一个很长的Resolver Chain(解析链)。

这里对于GraphQL的解析过程只是很简单的概括,其内部运行机制远比这个复杂,当然这些对于使用者是黑盒的,我们只需要大概了解它的过程即可。

Resolver本身的声明在各个语言中是不一样的,因为它代表数据获取的具体逻辑。它的函数签名(以js为例子)如下:

function(parent, args, ctx, info) {
    ...
}

其中的参数的意义如下:

  • parent: 当前上一个Resolver的返回值
  • args: 传入某个Query中的函数(比如上面例子中article(id: Int)中的id
  • ctx: 在Resolver解析链中不断传递的中间变量(类似中间件架构中的context)
  • info: 当前Query的AST对象

值得注意的是,Resolver内部实现对于GraphQL完全是黑盒状态。这意味着Resolver如何返回数据、返回什么样的数据、从哪返回数据,完全取决于Resolver本身,基于这一点,在实际中,很多人往往把GraphQL作为一个中间层来使用,数据的获取通过Resolver来封装,内部数据获取的实现可能基于RPC、REST、WS、SQL等多种不同的方式。同时,基于这一点,当你在对一些未使用GraphQL的系统进行迁移时(比如REST),可以很好的进行增量式迁移。

总结

大概就这么多,首先感谢你耐心的读到这里,虽然题目是30分钟熟悉GraphQL核心概念,但是可能已经超时了,不过我相信你对GraphQL中的核心概念已经比较熟悉了。但是它本身所涉及的东西远远比这个丰富,同时它还处于飞速的发展中。

最后我尝试根据这段时间的学习GraphQL的经验,提供一些进一步学习和了解GraphQL的方向和建议,仅供参考:

想进一步了解GraphQL本身

我建议再仔细去官网,读一下官方文档,如果有兴趣的话,看看GraphQL的spec也是极好的。这篇文章虽然介绍了核心概念,但是其他一些概念没有涉及,比如Union、Interface、Fragment等等,这些概念均是基于核心概念之上的,在了解核心概念后,应当会很容易理解。

偏向服务端

偏向服务端方向的话,除了需要进一步了解GraphQL在某个语言的具体生态外,还需要了解一些关于缓存、上传文件等特定方向的东西。如果是想做系统迁移,还需要对特定的框架做一些调研,比如graphene-django。

如果是想使用GraphQL本身做系统开发,这里推荐了解一个叫做prisma的框架,它本身是在GraphQL的基础上构建的,并且与一些GraphQL的生态框架兼容性也较好,在各大编程语言也均有适配,它本身可以当做一个ORM来使用,也可以当做一个与数据库交互的中间层来使用。

偏向客户端

偏向客户端方向的话,需要进一步了解关于graphql-client的相关知识,我这段时间了解的是apollo,一个开源的grapql-client框架,并且与各个主流前端技术栈如Angular、React等均有适配版本,使用感觉良好。

同时,还需要了解一些额外的查询概念,比如分页查询中涉及的Connection、Edge等。

大概就这么多,如有错误,还望指正。

欢迎关注公众号 全栈101,只谈技术,不谈人生
clipboard.png
查看原文