对外提供的API如何保证幂等?
举例说明:银联提供的付款接口:需要接入商户提交付款请求时附帯: source来源,seq序列号source+seq在数据库里面做准一索引,防止多次付款（井发）时,只能处理一个请求
重点:对外提供接口为了支持写等调用,接口有两个字段必须传,一个是来源 source,个是来源方序列号seq,这个两个字段在提供方系统里面做联合唯一索引,这样当第三方调用时,先在本方系统里面查询一下,是否已经处理过,返回相应处理结果;没有处理过,进行相应处理,返回结果
注意,为了幂等友好,一定要先查词一下,是否处理过该笔业务,不查询直接插入业务系统,会报错,但实际已经处理

先做一个说明,从理论上来说,给缓存设置过期时间,是保证最终一致性的解决方案。这种方案下,我们可以对存入始存的る据置过期时间,所有的写操作以数据库为准,对媛存操作只是尽最大努力更新即可。也就是说如果数据写成功,存更新失败,那么只要到达过明时间,则后面的读请求自然会从数据库中读取新值然后回填媛存因此,接下来讨论的思路不依赖于给媛存设置过明时间这个方察在这里,我们讨论三种更新策略:
1.先更新缓存,再更新数据库。(不可取)
2.先更新数据库,再更新媛存。(不可取)
3.先删除缓存,再更新数据库。(不可取)
4.先更新数据库,再删除缓存,(可取,有问题情解大前提:
先读缓存,如果缓存没有,才从数据库读取
(1)先更新数据库,再更新缓存
这套方案,大家是普遍反对的,为什么呢?有如下两点原因。原因一(线程安全角度)
同时有请求A和请求B进行更新操作,那么会出现
(1)线程A更新了数据库
(2)线程B更新了敬据库
(3)线程B更新了缓存
(4)线程A更新了缓存
这就出现请求A更新存应该比请求B更新存早才对,但是因为网络等原因,B却比A更早更新缓了存。这就导致了脏数据,因此不考虑。原因二(业务场景角度)有如下两点:
tn日
写数据库场比较多

(3守据库,再刪缓存
首先,先说一下。老外提出了一个缓存更新套路,名为《 Cache- Aside pattern》。其中就指出
・失效:应用程序先从 cache取数据,没有得到,则从数据库中取数据,成功后,放到媛存中。
・命中:应用程序从 cachet中取数据,取到后返回。
・更新:先把数据存到数据库中,成功后,再让缓存失效。
另外,知名社交网站 facebook也在论文《 Scaling Memcache at Facebook》中提出,他们用的也是先更新数据库,再媛存的策略。这种情况不存在井发问题么?
不是的。假设这会有两个请求,一个请求A做查询操作,一个请求B做更新操作,那么会有如下情形产生
(1)缓存刚好失效
(2)请求A查询数据库,得个旧值
(3)请求B将新值写入数据库
4)请求B除媛存
(5)请求A将查到的日值写入媛存
ok,如果发生上述情况,确实是会发生脏数据。然而,发生这种情况的概率又有多少呢?
发生上述情况有一个先天性条件,就是步骤(3)的写数据库操作比步骤(2)的读数据库操作耗时更短,才有可能使得步骤(4)先于步骤(5)。可是,大家想想,数据库的读操作的速度远快于写操作的(不然做读写分离干嘛,做读写分离的意义就是因为读操作比较快,耗资源少),因此步骤(3)耗时比步骤(2)更短,这一情形很难出现
假设,有人非要抬杠,有强迫症,一定要解决怎么办?如何解决上述井发问题?
首先,给存设有效时间是一种方案。其次,采用策略(2)里给出的异步延时除策略,保证读请求完成以后,再进行删除操作。

认证和授权的区别Authentication(认证)是验证您的身份的凭据(例如用户名和密码),通过这个凭据,系统得以知道你就是你,也就是说系统存在你这个用户。所以, Authentication被称为身份/用户验证
Authorization(授权)发生在 Authentication(认证)之后。授权,它主要掌管我们访问系统的权限。比如有些特定资源只能具有特定权限的人才能访问比如 admin,有些对系统资源操作比如期除、添加、更新只能特定人才具
这两个般在我们的系统中被结合在一起使用,目的就是为了保护我们系统的安全性

什么是 Token?什么是JMT?如何基于 Token进行身份验证?
我们知道 Session信息需要保存一份在服务器端。这种方式会带来一些麻烦,比如需要我们保证保存 Session信思服务器的可用性、不适合移动端(不依赖 Cookie)等
有没有一种不需要自己存放 Session信息就能实现身份验证的方式呢?使用 Token即可!WT( SON Web
Token)就是这种方式的实现,通过这种方式服务器端就不需要保存 Session数据了,只用在客户端保存服务端返回给客户的 Token就可以了,扩履性得到提升
MT本质上就一段签名的SON格式的数据。由于它是帯有签名的,因此接收者便可以验证它的真实性
下面是RFC7519对MT做的较为正式的定义。
JSON Web Token (WT) is a compact, Url-safe means of representing claims to be transferred between twoparties. The claims in a WT are encoded as a JSON object that is used as the payload of a )SON Web
Signature UWS)structure or as the plaintext of a JSON Web Encryption(WE)structure, enabling the claimsto be digitally signed or integrity protected with a Message Authentication Code(MAC)and/or encrypted.
–JSON Web Token (WT)
MT由3部分构成
Header描述MT的元数据。定义了生成签名的算法以及 Token的类型。
Payload(负载):用来存放实际需要传進的数据
Signature(签名):服务器通过 Payload、 Header和一个密钥 secret)使用 Header里面指定的签名算法(认是
HMAC SHA256)生成
在基于 Token进行身份验证的的应用程序中,服务器通过 Payload、 Headers和一个密钥 secret)的建令牌( Token)并将 Token发送给客户端,客户端将 Token保存在 Cookie或者 totalstorage里面,以后客户端发出

为什么 Cookie无法防止CSRF攻击,而 token可以
CSRF( Cross Site Request Forgery)-般被甜译为站请求伪造。那么什么是站请求伪造呢?说简单一点用你的身份去发送一些对你不友好的请求,举个简单例子:
小壮登录了某网上银行,他来到了网上银行的帖子区,看到一个帖子下面有一个链接写着科学理财,年收益率70%°,小杜好奇的点开了这个链接,结果发现自己的账户少了10000元,这是这么回事呢?原来黑客在链接中藏了一个请求,这个请求直接利用小社的身份给银行发送了一个转账请求也就是通过你的 Cookie向银行发出请求<asrc=htpi/www.mybank.com/Transfer?banked=11&money.=10000科学理财,年收益率70%<,原因是进行 Session认证的时候,我们一般使用 Cookie来存储 Session,当我们登陆后后端生成个 Session放在
Cookie中返回给客户端,服务端通过 Redis或者其他存储工具记录保存着这个5 ession,客户端登录以后每次请求都会带上这个 Session,服务端通过这个 Session来标示你这个人。如果别人通过 cookie拿到了 Session后就可以代皆你的身份访问系统了
Session认证中 Cookie中的 Session是由览器发送到服务端的,借助这个特性,攻击者就可以通过让用户误点攻击链接,达到攻击效果
但是,我们使用 token的话就不会存在这个问题,在我们登录成功获得 token之后,一般会选择存放在locastorage中。然后我们在前端通过某些方式会始每个发到后端的请求加上这个 token.这样就不会出现CSRF同的问题。因为,即使有个你点击了非法链接发送了请求到服务端,这个非法请求是不会携帯 token的,所以这个请求将是非法的。

分布式架构下, Session共享有什么方案?
1.不要有 session:但是确实在某些场景下,是可以没有 session的,其实在很多接口类系统当中,都提倡【API无状态服务】:也就是每一次的接口访问,都不依于 session、不依赖于前一次的接口访问,用W的
2.存入 cookies中:将 session存储到 cookie中,但是缺点也很明显,例如每次请求都得带着 session,数据存储在toker
客户端本地,是有风险的
3. session同步:对个服务器之间同步 session,这样可以保证每个服务器上都有全部的 session信息,不过当服
务器数量比较多的时候,同步是会有延退甚至同步失败
4.我们现在的系统会把 session放到 Redis.中存储,虽然架构上変得复杂,并且需要多访问一次 Redis,但是这种方案来的好处也是很大的:实现 session共享,可以水平扩展(増加加 Redis服务器),服务器重启 session不丢失(不过也要注意 session在 Redist中的刷新/失效机制),不仅可以跨服务器 sessi0n共享,甚至可以跨平台
(例如口网页端和AP端满)进行共享
5.使用 Nginx(或其他复杂均衡软硬件)中的p绑定策略,同个p只能在指定的同一个机器访问,但是这样做风险也比较大,而且也是去了负載均的意

springcloudi核心组件有哪些,分别有什么作用
服务注册与发现ー- Netflix Eureka、 Nacos、 Zookeeper客户端负载均衡一一 Netflix Ribbon、 Springcloud Loadbalancer
服务熔断
Netflix Hystrix、 Alibaba Sentinel、 Resilience.4服务网关ー- Netflix Zuu、 Springcloud Gateway服务接口调用一- Netflix Feign、 Resttemplate、 Openfeint链路追琮ー- Netflix Sleuth、 Skywalking、 Pinpoint聚合 Hystrix监控数据一- Netflix Turbine监控中心- Springboot Admin
配置中心ー- Spring Cloud Config、 Apollo, nacos

注册中心的原理是什么
服务启动后向 Eureka注册, Eureka Server会将注册信息向其他 Eureka Server进行同步,当服务费者要调用服务提供者,则向务注册中心获取服务提供者地址,然后会将服务提供者地址存在本地,下次再调用时,则直接
从本地存中获取服务列表来亮成服务调用