1. 背景

某天凌晨一点多，服务挂了，日志戛然而止，grafanar监控内存，cpu、磁盘都是正常的，该怎么去排查

2. 排查手段

观测日志、是否有程序触发关闭jvm进程，system.exit()，观测内存，cpu，磁盘，是否有因为机器资源不够分配的问题导致进程被机器kill

观测机器的操作日志/var/log/messages，直接搜索kill 的日志

messages 日志是核心系统日志文件。它包含了系统启动时的引导消息，以及系统运行时的其他状态消息。IO 错误、网络错误和其他系统错误都会记录到这个文件中。其他信息，比如某个人的身份切换为 root，也在这里列出。如果服务正在运行，比如 DHCP 服务器，您可以在 messages 文件中观察它的活动。通常，/var/log/messages 是您在做故障诊断时首先要查看的文件。

/var/log/messages文件中存放的就是系统的日志信息,当内核程序调试时,printk语句所产生的信息显示不出来的时候,就使用cat /var/log/messages文件的方法,查看所打印出的信息.

都没问题了，直接联系运维看一下，开发也没有绝对百分百的手段判断进程挂的原因，最终判断为阿里云系统错误导致机器重启

作者：斯瓦辛武
来源：juejin.cn/post/7254542743098818621

前言

短信作为一种便捷、快速的通信方式，已经在我们的日常生活中得到广泛应用。无论是个人通信、企业沟通还是身份验证等场景，短信都发挥着重要的作用。而实现短信功能的核心是短信实现原理和验证码短信API。

本文将介绍短信实现的基本原理以及 验证码短信API，帮助读者更好地了解短信技术和应用。

实现原理（步骤）

1. 
   

   触发事件：通知短信的实现通常是作为某种事件的响应而触发的。例如，用户完成了注册、下单、密码重置等操作，这些事件可以触发发送通知短信。

   
   


2. 
   

   业务逻辑处理：在触发事件后，相关的业务逻辑将被执行。这可能包括生成通知内容、确定接收者等。

   
   


3. 
   

   调用短信服务提供商的API：为了发送短信，系统将调用短信服务提供商的API。这些提供商通常是专门的短信网关或通信运营商，提供发送短信的基础设施和服务。

   
   


4. 
   

   构建短信内容：在调用短信服务提供商的API之前，系统需要构建短信的内容。这包括编写文本消息、添加动态变量或链接等。通常，短信内容可以包含特定的占位符，用于在发送时插入动态数据，如用户名、订单号等。

   
   


5. 
   

   调用短信服务API发送短信：使用短信服务提供商的API，系统将发送短信请求。这通常涉及向API端点发送HTTP请求，包括目标手机号码、短信内容和身份验证信息等。

   
   


6. 
   

   短信服务商处理：短信服务提供商接收到发送短信的请求后，会进行一系列的处理步骤。这可能包括验证发送者的身份、检查短信内容的合法性、处理短信队列等。

   
   


7. 
   

   短信传递：一旦短信服务提供商完成处理，它会将短信传递到相应的目标手机号码。这通常是通过与移动网络运营商之间的通信渠道实现的。

   
   


8. 
   

   接收短信：目标手机号码的手机将接收到短信，并在短信应用程序中显示。用户可以查看和阅读通知短信的内容。

   
   

验证码短信API

在短信实现原理中，必不可少的一个东西就是 —— 短信API，只有调用了 短信API 我们才能把短信发送出去。

在 短信API 中最常见的就是 验证码短信API 和 通知短信API。在之前说过了通知短信，今天就说一说 验证码短信API。短信API 我们可以去网上各个平台查看，我这里使用的是 APISpace 的 验证码短信API~

以 JavaScript 为例的调用示例代码：

var data = "{"msg":"【Eolinker】尊敬的用户{$var}，欢迎联调通知短信。","params":"15800000000,张先生;13200000000,王小姐","sendtime":"","extend":"","uid":""}"



$.ajax({

    "url":"https://eolink.o.apispace.com/sms-notify/notify",

    "method": "POST",

    "headers": {

        "X-APISpace-Token":"",

        "Authorization-Type":"apikey",

        "Content-Type":"application/json"

    },

    "data": data,

    "crossDomain": true

})

    .done(function(response){})

    .fail(function(jqXHR){})

验证码短信应用场景

1. 
   

   注册和登录验证：许多网站、应用和服务在用户注册和登录过程中使用验证码短信来验证用户的身份。用户在提供手机号码后，会收到包含验证码的短信，然后需要输入验证码才能完成注册或登录过程。这样可以确保用户提供的手机号码是有效的，并增加账户的安全性。

   
   


2. 
   

   密码重置和账户安全：当用户忘记密码或账户出现异常时，验证码短信可以用于重置密码或确保账户安全。通过发送验证码短信，用户可以通过验证自己的身份来重新设置密码，或者确认是否进行了某些账户操作，如更改手机号码或绑定新设备。

   
   


3. 
   

   手机号码验证：许多平台需要验证用户提供的手机号码的真实性，以保护用户账户的安全性。验证码短信可以用于验证用户拥有指定手机号码，并通过让用户输入验证码来确认其所有权。

   
   


4. 
   

   交易和支付安全：在电子商务和移动支付中，验证码短信被广泛用于交易和支付的安全验证。用户在进行支付或敏感操作时，会收到包含验证码的短信，需要输入正确的验证码才能完成交易或操作，以防止未经授权的访问和欺诈行为。

   
   


5. 
   

   帐户活动通知：验证码短信也可以用于向用户发送帐户活动通知，例如当用户进行重要操作、更改账户信息、进行高风险活动等时，发送验证码短信以提醒用户并增加账户的安全性。

   
   

结束语

通过本文的介绍，我们对短信实现原理以及 验证码短信API 有了一定的了解。短信作为一种简单而高效的通信方式，在各个领域都发挥着重要的作用。验证码短信API为开发者提供了便捷的工具，使他们能够轻松地集成和使用验证码短信功能。无论是个人用户还是企业开发者，都可以利用短信技术和API来实现更安全、高效的通信和身份验证。随着移动通信技术的不断发展，我们相信短信技术将继续在各个领域发挥重要作用，并为我们的生活带

你好，我是悟空。

我的师父是唐玄奘~

西游记的故事想必大家在暑假看过很多遍了，为了取得真经，唐玄奘历经苦难，终于达成。

在途经各国的时候，唐玄奘都会拿出一个通关文牒交给当地的国王进行盖章，方能通过。

本篇目录如下：

通关文牒

通关文牒就是唐朝官方发的一个凭证，证明持有人来自东土大唐，一般是使臣持有。

有了这个凭证后，到其他国家，比如女儿国国王看到这个凭证后，就会放行。

下面来一张西游记中通关文牒的生命周期图。

长安是一个颁发凭证（通关文牒）的微服务节点，乌鸡国、女儿国和大雷音寺等都是集群中的一个微服务节点，唐玄奘拿着凭证访问各国。

那为什么别的国家认可这个凭证呢？

那是因为当时的唐朝非常强大，有很多国家都要向唐朝朝贡，与唐朝交好有很多好处的~

朝贡也有篇故事哦~唐太宗把微服务的“心跳机制”玩到了极致！

唐太宗在通关文牒上写道：“倘到西邦诸国，不灭善缘，照牒放行，须至牒者。 ”

意思就是说唐玄奘法师是我们唐朝的使臣，如果途经诸侯国，希望大家放行。

贞观之治时期的唐朝是在经济文化上都无比繁盛，国力强盛，周边国家都希望和唐朝建立友好关系，看到是唐朝使臣来了，好生招待下，然后盖章放行，给唐朝留个好印象。

在安全架构中，凭证 出现得太频繁了，比如我们在网关这一层加的校验令牌，其实就是校验凭证。

凭证是什么

凭证（Credentials）的出现就是系统保证它与用户之间的承诺是双方当时真实意图的体现，是准确、完整且不可抵赖的。

那唐太宗给唐玄奘的通关文牒就是一个凭证，上面盖着唐朝的官印、唐太宗的亲笔，这充分体现了持有者是拥有一个可信的令牌的，而且这个通关文牒上的官印是不可篡改的，如果改了，其他国家就不认了。

上面这种模式其实对应的是一种普通的认证授权模式，而大名鼎鼎的 OAuth 2.0 认证授权模式虽然有五种模式，但他们殊途同归，最后的目的都是生成一个凭证给到客户端，让客户端持有这个凭证来访问资源。关于 OAuth2.0 本篇不做展开。

关于凭证的存储方案，业界的安全架构中有两种方案：

• Cookie-Session 模式


• JWT 方案

Cookie-Session 模式

流程图如下：

用户登录认证通过后，后端会存放该客户端的身份信息，也就是存放到 session 中，session 可以用来区分不同，然后返回一个 sessionId 给到客户端。

客户端将 sessionId 缓存在客户端。当客户端下次发送 HTTP 请求时，在 header 的 cookie 字段附带着 sessionId 发送给后端服务器。

后端服务器拿到 header 中的 sessionId，然后根据 sessionId 找到 session，如果 session 存在，则从 session 中解析出用户的身份信息，然后执行业务逻辑。

我们都知道 HTTP 协议是一种无状态的传输协议，无状态表示对一个事务的处理没有上下文的记忆能力，每一个 HTTP 请求都是完全独立的。但是 Cookie-Seesion 模式却和 HTTP 无状态特性相悖，因为客户端访问资源时，是携带第一次拿到的 sessionId 的，让服务端能够顺利区分出发送请求的用户是谁。

服务端对 session 的管理，就是一种状态管理机制，该机制存储了每个在线用户的上下文状态，再加上一些超时自动清理的管理措施。Cookie-Session 也是最传统但今天依旧应用到大量系统中，由服务端与客户端联动来完成的状态管理机制。

放到西游记中，如果用这种 Cookie-Session 模式是怎么样的呢？

我们把唐朝和周边国家想想成一个分布式集群，所有国家都需要将唐玄奘这个使者信息都保存一份（分布式存储），当唐玄奘路过某个国家时，需要查询本地存储中是否有唐玄奘，如果有，则认为唐玄奘是合法的使者，可以放行。

但是这种方式就会需要每个国家都同步保存，同步的成本是非常高昂的，而且会有同步延迟的存在。

Cookie-Session 模式的优势

状态信息都存储于服务器，只要依靠客户端的同源策略和 HTTPS 的传输层安全，保证 Cookie 中的键值不被窃取而出现被冒认身份的情况，就能完全规避掉上下文信息在传输过程中被泄漏和篡改的风险。Cookie-Session 方案的另一大优点是服务端有主动的状态管理能力，可根据自己的意愿随时修改、清除任意上下文信息，譬如很轻易就能实现强制某用户下线的这样功能。（来自凤凰架构）

Cookie-Session 模式的劣势

在单节点的单体服务中再适合不过，但是如果需要水平扩展要部署集群就很麻烦。

如果让 session 分配到不同的的节点上，不重复地保存着一部分用户的状态，用户的请求固定分配到对应的节点上，如果某个节点崩溃了，则里面的用户状态就会完全丢失。如果让 session 复制到所有节点上，那么同步的成本又会很高。

而为了解决分布式下的认证授权问题，并顺带解决少量状态的问题，就有了 JWT 令牌方案，但是 JWT 令牌和 Cookie-Session 并不是完全对等的解决方案，JWT 只能处理认证授权问题，且不能说 JWT 比 Cookie-Session 更加先进，也不可能全面取代 Cookie-Seesion 机制。

JWT 方案

我们上面说到 Cookie-Session 机制在分布式环境下会遇到一致性和同步成本的问题，而且如果在多方系统中，则更不能将 Session 共享存放在多方系统的服务端中，即使服务端之间能共享数据，Cookie 也没有办法跨域。

转换思路，服务端不保存任何状态信息，由客户端来存储，每次发送请求时携带这个状态信息发给后端服务。原理图如下所示：

但是这种方式无法携带大量信息，而且有泄漏和篡改的安全风险。信息量大小受限没有比较好的解决方案，但是确保信息不被中间人篡改则可以借助 JWT 方案。

JWT（JSON WEB TOKEN）是一种令牌格式，经常与 OAuth2.0 配合应用于分布式、多方系统的应用系统中。

我们先来看下 JWT 的格式长什么样：

以上截图来自 JWT 官网（jwt.io），数据则是悟空随意编的。

左边的字符串就是 JWT 令牌，JWT 令牌是服务端生成的，客户端会拿着这个 JWT 令牌在每次发送请求时放到 HTTP header 中。

而右边是 JWT 经过 Base64 解码后展示的明文内容，而这段明文内容的最下方，又有一个签名内容，可以防止内容篡改，但是不能解决泄漏的问题。

JWT 格式

JWT 令牌是以 JSON 结构存储，用点号分割为三个部分。

第一部分是令牌头（Header），内容如下所示：

{

  "alg": "HS256",

  "typ": "JWT"

}

它描述了令牌的类型（统一为 typ:JWT）以及令牌签名的算法，示例中 HS256 为 HMAC SHA256 算法的缩写，其他各种系统支持的签名算法可以参考jwt.io/网站所列。

令牌的第二部分是负载（Payload），这是令牌真正需要向服务端传递的信息。但是服务端不会直接用这个负载，而是通过加密传过来的 Header 和 Payload 后再比对签名是否一致来判断负载是否被篡改，如果没有被篡改，才能用 Payload 中的内容。因为负载只是做了 base64 编码，并不是加密，所以是不安全的，千万别把敏感信息比如密码放到负载里面。

{

  "sub": "passjava",

  "name": "悟空聊架构",

  "iat": 1516239022

}

令牌的第三部分是签名（Signature），使用在对象头中公开的特定签名算法，通过特定的密钥（Secret，由服务器进行保密，不能公开）对前面两部分内容进行加密计算，以例子里使用的 JWT 默认的 HMAC SHA256 算法为例，将通过以下公式产生签名值：

HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload) , secret)

签名的意义：确保负载中的信息是可信的、没有被篡改的，也没有在传输过程中丢失任何信息。因为被签名的内容哪怕发生了一个字节的变动，也会导致整个签名发生显著变化。此外，由于签名这件事情只能由认证授权服务器完成（只有它知道 Secret），任何人都无法在篡改后重新计算出合法的签名值，所以服务端才能够完全信任客户端传上来的 JWT 中的负载信息。

JWT 的优势

• 无状态：不需要服务端保存 JWT 令牌，也就是说不需要服务节点保留任何一点状态信息，就能在后续的请求中完成认证功能。


• 天然的扩容便利：服务做水平扩容不用考虑 JWT 令牌，而 Cookie-Session 是需要考虑扩容后服务节点如何存储 Session 的。


• 不依赖 Cookie：JWT 可以存放在浏览器的 LocalStorage，不一定非要存储在 Cookie 中。

JWT 的劣势

• 令牌难以主动失效：JWT 令牌签发后，理论上和认证的服务器就没有什么关系了，到期之前始终有效。除非服务器加些特殊的逻辑处理来缓存 JWT，并来管理 JWT 的生命周期，但是这种方式又会退化成有状态服务。而这种要求有状态的需求又很常见：譬如用户退出后，需要重新输入用户名和密码才能登录；或者用户只允许在一台设备登录，登录到另外一台设备，要求强行退出。但是这种有状态的模式，降低了 JWT 本身的价值。


• 更容易遭受重放攻击：Cookie-Session 也有重放攻击的问题，也就是客户端可以拿着这个 cookie 不断发送大量请求，对系统性能造成影响。但是因为 Session 在服务端也有一份，服务端可以控制 session 的生命周期，应对重放攻击更加主动一些。但是 JWT 的重放攻击对于服务端来说就很被动，比如通过客户端的验证码、服务端限流或者缩短令牌有效期，应用起来都会麻烦些。


• 存在泄漏的风险：客户端存储，很有可能泄漏出去，被其他人重复利用。


• 信息大小有限：HTTP 协议并没有强制约束 Header 的最大长度，但是服务器、浏览器会做限制。而且如果令牌很大还会消耗传输带宽。

真假美猴王

西游记中还有一个章节，假的美猴王带着通关文牒和其他行李跑到了花果山，还想自行取经，这不就是盗用  JWT 令牌了吗？

如何使用 JWT

Java 有现成的工具类可以使用，而且校验 JWT 的工作可以统一交给网关来做，这个就是下一篇要重点讲解的实战内容了。

总结

唐玄奘就好比客户端，通关文牒就好比 JWT 令牌，经过的每个国家就好比集群中的微服务。

唐玄奘借助 JWT 令牌的认证授权模式，一路通关，最终取得真经，是不是很酷呀~

下一篇：手摸手实战 Spring Cloud Gateway + JWT 认证功能

参考资料：

《凤凰架构》

《OAuth2.0 实战》

作者：悟空聊架构
来源：juejin.cn/post/7250029300820869178

本文将通过复制场景下的异常分析，介绍手工搭建MySQL主从复制时需要注意的关键细节。

作者：秦福朗

爱可生 DBA 团队成员，负责项目日常问题处理及公司平台问题排查。热爱互联网，会摄影、懂厨艺，不会厨艺的 DBA 不是好司机，didi~

本文来源：原创投稿

• 爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

背景

有人反馈装了一个数据库，来做现有库的从库。做好主从复制关系后，在现有主库上使用 show slave hosts; 管理命令去查询从库的信息时，发现从库的 IP 地址竟是自己的 IP 地址，这是为什么呢？

因生产环境涉及 IP，端口等保密信息，以下以本地环境来还原现象。

本地复现

基本信息

问题现象

不多说，先上图，以下为在主库执行 show slave hosts; 出现的现象：

可以看到这里的 Host 是主库的 IP 地址。

我们登陆从库查看一下 show slave status\G：

mysql> show slave status\G

*************************** 1. row ***************************

               Slave_IO_State: Waiting for master to send event

                  Master_Host: 10.186.65.33

                  Master_User: universe_op

                  Master_Port: 6607

                Connect_Retry: 60

              Master_Log_File: mysql-bin.000002

          Read_Master_Log_Pos: 74251749

               Relay_Log_File: mysql-relay.000008

                Relay_Log_Pos: 495303

        Relay_Master_Log_File: mysql-bin.000002

             Slave_IO_Running: Yes

            Slave_SQL_Running: Yes

我们看到确实从库是在正常运行的，且复制的源就是主库。

为什么执行 show 命令看到的 Host 和实际的情况对不上呢？

查阅资料

首先查阅官方文档，关于 show slave hosts; 语句的解释：

• 首先说明 8.0.22 之后版本的 show slave hosts 语句被废弃（可执行），改为 show replicas，具体机制还是一样的。


• 这里说明了各个数据的来源，多数来源于 report-xxxx 相关参数，其中 Host 的数据来自于从库的 report_host 这个参数。

然后，我们测试在从库执行 show variables like "%report%";。

mysql> show variables like "%report%";

+-----------------+--------------+

| Variable_name   | Value        |

+-----------------+--------------+

| report_host     | 10.186.65.33 |

| report_password |              |

| report_port     | 6607         |

| report_user     |              |

+-----------------+--------------+

4 rows in set (0.01 sec)

可以看到这里显示的就是主库的 IP。

我们再查询 report_host 的参数基本信息：

可以看到该参数非动态配置，在从库注册时上报给主库，所以主库上执行 show slave hosts; 看到的是 IP 是从这里来的，且无法在线修改。

最后也通过查看从库上的 my.cnf 上的 report_port 参数，证实确实是主库的 IP：

结论

经了解，生产上的从库是复制了主库的配置文件来部署的，部署时没有修改 report_host 这个值，导致启动建立复制后将 report_host 这个 IP 传递给主库，然后主库查询 show slave hosts 时就出现了自己的 IP，让主库怀疑自己的从库竟然是自己。

生产上大部分人知道复制主库的配置文件建立新库要修改 server_id 等相关 ID 信息，但比较容易忽略掉 report_ip、report_port 等参数的修改，这个需要引起注意，虽然错误之后看起来对

1. 什么是短链？

在使用网址访问访问网站的时候，可能都会遇到一个很长的链接，多则可能几百个字符，这样的链接看起来非常的长

https://www.google.com/search?q=%E9%95%BF%E9%93%BE%E9%93%BE%E6%8E%A5&rlz=1C5GCEM_enCN1065&oq=%E9%95%BF%E9%93%BE%E9%93%BE%E6%8E%A5&aqs=chrome..69i57j0i13i512j0i10i13i512l2j0i13i30j0i10i13i30j0i13i30l4.4703j0j15&sourceid=chrome&ie=UTF-8

像以上这种，就是长链链接，看起来非常的臃肿，虽然说链接里面携带的一些参数使链接变长是不可避免的，但是我们可以使用另一种方法，既能使链接携带参数也能使链接为短链接，后面会讲到短链的原理和实现方式。

https://juejin.cn/post/7254039051588599864

像以上这种就是短链，使用短链有以下几种优点。

1. 相比长链更加简洁。


2. 便于使用，粘贴复制分享给别人时较为便捷，有些平台对分享内容的长度有所限制（微博只能发140字），这个时候使用短链可以输入更多的内容。


3. 短链生成的二维码更容易识别。

2. 短链的原理

实现短链的核心原理就是链接映射表和302临时重定向

当我们用户用短链访问服务器时，服务器会将用户携带的短链在服务器中的链接映射表中寻找唯一与之对应的长链接，寻找到后返回重定向，重定向至长链接的网页，这样用户就可以不直接携带长链接，而是携带一个短链接，间接的去访问长链接，这个中间层就是服务器，服务器会在中间做一个链接映射和重定向的操作。

3. 短链的实现方式

3.1. 自增id法

自增ID的方法也叫做永不重复法，即采用发号器原理来实现，每一个url对应一个数字，然后自增，可以理解为ID，然后将ID进行相应的转换（比如进制转换），由于ID是唯一的，所以转换出来的结果也是唯一的。短网址的长度一般设为 6 位，而每一位是由 [a - z, A - Z, 0 - 9] 总共 62 个字母组成的，所以 6 位的话，总共会有 62^6 ~= 568亿种组合，基本上够用了。

3.2. 算法生成

将长链接做一次哈希算法之后就可以生产一个短链接。

我们都知道哈希算法是一种摘要算法，它的作用是：对任意一组输入数据进行计算，得到一个固定长度的输出摘要。

我们常见的哈希算法有：MD5、SHA-1、SHA-256、SHA-512 算法等。但我们最好还是使用另一种叫做 MurmurHash 的哈希算法。

因为 MD5 和 SHA 哈希算法，它们都是加密的哈希算法，也就是说我们无法从哈希值反向推导出原文，从而保证了原文的保密性。

但对于我们这个场景而言，我们并不关心安全性，我们关注的是运算速度以及哈希冲突。而 MurmurHash 算法是一个非加密哈希算法，所以它的速度回更快。

哈希冲突

学过 HashMap 的同学都知道，哈希冲突是哈希算法不可避免的问题。而解决哈希冲突的方式有两种，分别是：链表法和重哈希法。HashMap 使用了链表法，但我们这里使用的是重哈希法。

所谓的重哈希法，指的是当发生哈希冲突的时候，我们在原有长链后面加上固定的特殊字符，后续拿

为撒我们要使用单点登录

通常情况下我们开发一套系统时，我们都会写一套登录页面。当用户需要访问系统时需要先进行账号登录然后进入系统使用。但是当我们有多个系统时难道需要用户登录多次吗？显然这种方式是不优雅的😶‍🌫️，此时就轮到单点登录登场了。本文将主要以前端的视角来聊一聊该如何落地单点登录。

单点登录的英文名叫做：Single Sign On（简称SSO）😶‍🌫️

单点登录能干嘛

简单粗暴的说单点登录就是

一处登录 处处登录 🤡

单点登录在前端的系统模型

单点登录实施方案

单点登录目前有两种方案

• cookie 共享方案(子域名方案)


• ticket 方案（凭证交换）

这两个方案是有共同点的，我们看看它们有哪些共同的部分

• 需要一个独立的登录系统


• 通用重定向的方式完成子系统登录

结合以上可以发现，这两个方案其实在前端的差异性并不大，主要就是需要考虑如何实现登录态共享。

cookie 共享方案

传统的登录方式是用户在登录页完成登录，然后后端通过 set-cookie 将 token 写入到浏览器的 cookie 当中之后的每次请求都会携带token完成身份验证。此时的登录模块和业务模块是同一系统下的不同页面。

单点登录模型下的登录模块和业务模块是独立的不同系统

结合以上流程图我们来分析一波，图中的A和sso都是example.com的子域名，当用户访问A-client时会向A-server发送身份验证请求检验当前请求是否携带有效token，如无效则返回特定 code A-client接到返回后根据 code 做出不同响应。

• A-server返回 token 有效，则继续保持对A-client的访问。


• A-server返回 token 无效。
  
  
  
  • 
    

    A-client重定向至SSO-client并携带redirect参数http://sso.example.com?redirect=a.example.com。

    
    
  
  
  • 
    

    当用户在SSO-client完成登录后(SSO-server 通过 set-cookie 设置 token 为子域名可访问)，再通过redirect参数重定向回A-client。

    
    
  
  
  • 
    

    回到A-client后A-client再次向A-server发起身份验证，这次请求会默认携带上domain=example.com的cookie.token，A-server收到token检验有效后，返回用户信息继续保持用户对A-client的有效访问。

    
    
  
  
  
  

至此单点登录的核心逻辑就梳理完成了。

注意：以上是以每套系统都有独立的后端服务(同源)做出的流程，但是有时候我们的后端服可能是同一个，这时候我们在 ABC系统中的请求可能会有跨域/跨站等问题。
解决办法也很多，需要看是跨域，还是跨站问题。
这里贴一个跨域的处理方法 note.youdao.com/s/Tjuuv8Mv 也可以用反向代理去规避跨域问题。

同源：协议+主机名+端口 都相同

同站：二级域名+顶级域名 相同即可

ticket 临时凭证

ticket 方案总体上和 cookie 方案总体差不多，主要区别在于获取 token 的形式不同。

cookie 方案主要是依赖浏览的特性来完成 token 共享。

ticket 则是由各系统携带 ticket 这个临时凭证去换取token

从上图可以看出 ticket 方案不同的地方在于：

• 
  

  用户首次访问A-client时 token 不存在A-client会重定向至SSO-client，当用户在SSO-client登录成功后SSO-server会 set-cookie 将 token 注入到浏览器中（7天免登录），并返回 ticket 参数SSO-client收到登录成功结果后再次带着 ticket 参数重定向回A-client (http://a.example.com?ticket=xxxxxxx)。

  
  


• 
  

  此时A-client时会多一个 ticket 参数。

  
  


• 
  

  当A-client中的 token 过期时或不存在时，如果 ticket 存在A-server就会带着ticket去请求SSO-server检验ticket是否有效，当SSO-server返回有效的话就表示用户在SSO中是有效登录的。

  
  


• 
  

  验证成功后A-server下发 token set-cookie 进A-client的cookie中。

  
  

至此完成登录。

以上多是以前端的角度在分析单点登录的实现逻辑，还有很多可以修改的地方。例如后端是同一套服务，token是放在cookie，还是local storage或是JS内存中都是根据业务需求改变的。

以及安全问题，这里就不展开讨论啦

这是一个很有意思却很少有人注意的问题。

当我用Google搜索MySQL这个关键词的时候，Google只提供了13页的搜索结果，我通过修改url的分页参数试图搜索第14页数据，结果出现了以下的错误提示：

百度搜索同样不提供无限分页，对于MySQL关键词，百度搜索提供了76页的搜索结果。

为什么不支持无限分页

强如Google搜索，为什么不支持无限分页？无非有两种可能：

• 做不到


• 没必要

「做不到」是不可能的，唯一的理由就是「没必要」。

首先，当第1页的搜索结果没有我们需要的内容的时候，我们通常会立即更换关键词，而不是翻第2页，更不用说翻到10页往后了。这是没必要的第一个理由——用户需求不强烈。

其次，无限分页的功能对于搜索引擎而言是非常消耗性能的。你可能感觉很奇怪，翻到第2页和翻到第1000页不都是搜索嘛，能有什么区别？

实际上，搜索引擎高可用和高伸缩性的设计带来的一个副作用就是无法高效实现无限分页功能，无法高效意味着能实现，但是代价比较大，这是所有搜索引擎都会面临的一个问题，专业上叫做「深度分页」。这也是没必要的第二个理由——实现成本高。

我自然不知道Google的搜索具体是怎么做的，因此接下来我用ES（Elasticsearch）为例来解释一下为什么深度分页对搜索引擎来说是一个头疼的问题。

为什么拿ES举例子

Elasticsearch（下文简称ES）实现的功能和Google以及百度搜索提供的功能是相同的，而且在实现高可用和高伸缩性的方法上也大同小异，深度分页的问题都是由这些大同小异的优化方法导致的。

什么是ES

ES是一个全文搜索引擎。

全文搜索引擎又是个什么鬼？

试想一个场景，你偶然听到了一首旋律特别优美的歌曲，回家之后依然感觉余音绕梁，可是无奈你只记得一句歌词中的几个字：「伞的边缘」。这时候搜索引擎就发挥作用了。

使用搜索引擎你可以获取到带有「伞的边缘」关键词的所有结果，这些结果有一个术语，叫做文档。并且搜索结果是按照文档与关键词的相关性进行排序之后返回的。我们得到了全文搜索引擎的定义：

全文搜索引擎是根据文档内容查找相关文档，并按照相关性顺序返回搜索结果的一种工具

网上冲浪太久，我们会渐渐地把计算机的能力误以为是自己本身具备的能力，比如我们可能误以为我们大脑本身就很擅长这种搜索。恰恰相反，全文检索的功能是我们非常不擅长的。

举个例子，如果我对你说：静夜思。你可能脱口而出：床前明月光，疑是地上霜。举头望明月，低头思故乡。但是如果我让你说出带有「月」的古诗，想必你会费上一番功夫。

包括我们平时看的书也是一样，目录本身就是一种符合我们人脑检索特点的一种搜索结构，让我们可以通过文档ID或者文档标题这种总领性的标识来找到某一篇文档，这种结构叫做正排索引。

而全文搜索引擎恰好相反，是通过文档中的内容来找寻文档，诗词大会中的飞花令就是人脑版的全文搜索引擎。

全文搜索引擎依赖的数据结构就是大名鼎鼎的倒排索引（「倒排」这个词就说明这种数据结构和我们正常的思维方式恰好相反），它是单词和文档之间包含关系的一种具体实现形式。

打住！不能继续展开了话题了，赶紧一句话介绍完ES吧！

ES是一款使用倒排索引数据结构、能够根据文档内容查找相关文档，并按照相关性顺序返回搜索结果的全文搜索引擎

高可用的秘密——副本（Replication）

高可用是企业级服务必须考虑的一个指标，高可用必然涉及到集群和分布式，好在ES天然支持集群模式，可以非常简单地搭建一个分布式系统。

ES服务高可用要求其中一个节点如果挂掉了，不能影响正常的搜索服务。这就意味着挂掉的节点上存储的数据，必须在其他节点上留有完整的备份。这就是副本的概念。

如上图所示，Node1作为主节点，Node2和Node3作为副本节点保存了和主节点完全相同的数据，这样任何一个节点挂掉都不会影响业务的搜索。满足服务的高可用要求。

但是有一个致命的问题，无法实现系统扩容！即使添加另外的节点，对整个系统的容量扩充也起不到任何帮助。因为每一个节点都完整保存了所有的文档数据。

因此，ES引入了分片（Shard）的概念。

PB级数量的基石——分片（Shard）

ES将每个索引（ES中一系列文档的集合，相当于MySQL中的表）分成若干个分片，分片将尽可能平均地分配到不同的节点上。比如现在一个集群中有3台节点，索引被分成了5个分片，分配方式大致（因为具体如何平均分配取决于ES）如下图所示。

这样一来，集群的横向扩容就非常简单了，现在我们向集群中再添加2个节点，则ES会自动将分片均衡到各个节点之上：

高可用 + 弹性扩容

副本和分片功能通力协作造就了ES如今高可用和支持PB级数据量的两大优势。

现在我们以3个节点为例，展示一下分片数量为5，副本数量为1的情况下，ES在不同节点上的分片排布情况：

有一点需要注意，上图示例中主分片和对应的副本分片不会出现在同一个节点上，至于为什么，大家可以自己思考一下。

文档的分布式存储

ES是怎么确定某个文档应该存储到哪一个分片上呢？

通过上面的映射算法，ES将文档数据均匀地分散在各个分片中，其中routing默认是文档id。

此外，副本分片的内容依赖主分片进行同步，副本分片存在意义就是负载均衡、顶上随时可能挂掉的主分片位置，成为新的主分片。

现在基础知识讲完了，终于可以进行搜索了。

ES的搜索机制

一图胜千言：

1. 客户端进行关键词搜索时，ES会使用负载均衡策略选择一个节点作为协调节点（Coordinating Node）接受请求，这里假设选择的是Node3节点；


2. Node3节点会在10个主副分片中随机选择5个分片（所有分片必须能包含所有内容，且不能重复），发送search request；


3. 被选中的5个分片分别执行查询并进行排序之后返回结果给Node3节点；


4. Node3节点整合5个分片返回的结果，再次排序之后取到对应分页的结果集返回给客户端。

注：实际上ES的搜索分为Query阶段和Fetch阶段两个步骤，在Query阶段各个分片返回文档Id和排序值，Fetch阶段根据文档Id去对应分片获取文档详情，上面的图片和文字说明对此进行了简化，请悉知。

现在考虑客户端获取990～1000的文档时，ES在分片存储的情况下如何给出正确的搜索结果。

获取990～1000的文档时，ES在每个分片下都需要获取1000个文档，然后由Coordinating Node聚合所有分片的结果，然后进行相关性排序，最后选出相关性顺序在990～1000的10条文档。

页数越深，每个节点处理的文档也就越多，占用的内存也就越多，耗时也就越长，这也就是为什么搜索引擎厂商通常不提供深度分页的原因了，他们没必要在客户需求不强烈的功能上浪费性能。

完。

圈复杂度：理解和降低代码复杂性

在软件开发中，代码的复杂性是一个重要的考量因素。圈复杂度是一种用于衡量代码复杂性的指标，它可以帮助开发者评估代码的可读性、可维护性和可测试性。本文将详细介绍圈复杂度的概念，并提供几种降低圈复杂度的方法。同时，我们还将探讨如何在前端开发中使用ESLint和VS Code工具来设置和检测圈复杂度。

什么是圈复杂度？

圈复杂度是由Thomas J. McCabe于1976年提出的一种软件度量指标，用于衡量程序中的控制流程复杂性。它通过计算代码中的判断语句和循环语句的数量来评估代码的复杂性。圈复杂度的值越高，代码的复杂性就越高，理解和维护代码的难度也就越大。

圈复杂度的计算方法是通过构建程序的控制流图，然后统计图中的节点数和边数来得出结果。每个判断语句（如if语句）和循环语句（如for循环）都会增加控制流图中的节点数和边数。圈复杂度的值等于图中边数减去节点数，再加上2。这个值表示了代码中独立路径的数量，即代码执行的可能路径数。

圈复杂度的计算方式可以通过以下步骤进行：

1. 
   

   首先，将程序转换为控制流图（Control Flow Graph，CFG）。控制流图是一种图形表示方法，用于描述程序中的控制流程，包括各种条件和循环语句。

   
   


2. 
   

   在控制流图中，每个节点表示程序中的一个基本块（Basic Block），即一组连续的语句序列，没有分支或跳转语句。

   
   


3. 
   

   接下来，计算控制流图中的节点数量（N）和边数量（E）。节点数量即为程序中的基本块数量，边数量表示基本块之间的控制流转移关系。

   
   


4. 
   

   根据以下公式计算圈复杂度（V）：
   
   V = E - N + 2

   
   

   公式中的2表示程序的入口和出口节点，因为每个程序都至少有一个入口和一个出口。

   
   

为什么要降低圈复杂度？

高圈复杂度的代码往往难以理解和维护。当代码的复杂性增加时，开发者需要花费更多的时间和精力来理解代码的逻辑和执行路径。这不仅增加了开发和调试的难度，还可能导致代码中隐藏的逻辑错误。

降低圈复杂度有助于提高代码的可读性和可维护性。简化代码结构可以使代码更易于理解，减少错误的引入，并提高代码的可测试性。此外，降低圈复杂度还有助于改善代码的性能，因为简单的代码通常执行更快。

如何降低圈复杂度？

以下是几种降低圈复杂度的常用方法：

1. 减少条件语句的嵌套

条件语句的嵌套是导致圈复杂度增加的常见原因之一。当条件语句嵌套层级过多时，代码的可读性和可维护性都会受到影响。为了降低圈复杂度，可以考虑使用早期返回（early return）的方式来减少条件语句的嵌套。通过在函数内部尽早返回结果，可以避免深层嵌套的条件判断。

function calculateGrade(score) {

  if (score >= 90) {

    return 'A';

  }

  if (score >= 80) {

    return 'B';

  }

  if (score >= 70) {

    return 'C';

  }

  return 'D';

}

2. 拆分复杂函数

函数的复杂性是导致圈复杂度升高的另一个常见原因。当一个函数包含过多的逻辑和操作时，它往往难以理解和维护。为了降低圈复杂度，可以将复杂的函数拆分成多个小函数，每个函数只负责一个特定的任务。这样可以提高代码的可读性和可维护性，并且使得每个函数的圈复杂度更低。

function calculateGrade(score) {

  if (score >= 90) {

    return 'A';

  }

  return calculateGradeForLowerScores(score);

}



function calculateGradeForLowerScores(score) {

  if (score >= 80) {

    return 'B';

  }

  if (score >= 70) {

    return 'C';

  }

  return 'D';

}

3. 使用循环和迭代替代重复的代码块

重复的代码块会增加代码的复杂性和重复性。为了降低圈复杂度，可以使用循环和迭代来替代重复的代码块。通过将重复的逻辑抽象成一个函数，并在循环中调用该函数，可以减少代码的重复性和复杂性。

function printNumbers() {

  for (let i = 1; i <= 10; i++) {

    console.log(i);

  }

}

4. 使用适当的数据结构和算法

选择适当的数据结构和算法可以帮助降低代码的复杂性和提高性能。例如，使用哈希表可以减少查找操作的复杂度，使用排序算法可以提高搜索和比较的效率。通过选择合适的数据结构和算法，可以降低代码的圈复杂度并提高代码的执行效率。

使用ESLint检测圈复杂度

ESLint是一个流行的JavaScript代码检查工具，它可以帮助开发者发现和修复代码中的问题，包括圈复杂度。ESLint提供了许多规则和插件，可以配置和检测圈复杂度。

在ESLint中，可以使用complexity规则来设置圈复杂度的阈值。通过在配置文件中设置适当的阈值，可以在代码检查过程中发现圈复杂度过高的代码段，并及时进行优化和重构。

// .eslintrc.js

module.exports = {

  rules: {

    complexity: ['error', 15], // 设置圈复杂度阈值为15

  },

};

使用VS Code工具检测圈复杂度

VS Code是一款流行的代码编辑器，它提供了许多插件和工具，可以帮助开发者提高代码质量和效率。在VS Code中，可以使用插件如ESLint、CodeMetrics等来检测圈复杂度。

安装ESLint插件后，可以在VS Code的设置中配置圈复杂度的阈值，并在编辑器中实时检测代码的圈复杂度。通过设置合适的阈值，可以在开发过程中及时发现和解决代码复杂性问题。

结论

圈复杂度是衡量代码复杂性的重要指标，通过降低圈复杂度可以提高代码的可读性、可维护性和可测试性。在前端开发中，使用ESLint和VS Code工具可以帮助我们设置和检测圈复杂度，并及时发现和解决代码中的复杂性问题。通过合理的代码设计和优化，我们可以编写出更简洁、高效和易于维护的代码。

希望本文对你理解圈复杂度以及降低

大家好，我是王老师，一直在准备写这篇稿子，但是事情太多一直耽误了，导致一直拖一直拖，结果就从最近变成了前一阵子。这下好了，不会有人说我蹭热度了。

大家都知道，前一阵子抖音和微博开始陆续上了IP归属地的功能，引起了众多热议。有大批在国外的老铁们开始"原形毕露"，被定位到国内来，那么IP归属到底是怎么实现的呢？那么网红们的归属地到底对不对呢？这篇文章帮大家揭晓。

一.第一步：如何拿到用户的真实IP

大家都知道，我们一般想访问公网，一般必须具备上网环境，那么我们开通宽带之后，运营商会给我们分配一个IP地址。一般IP地址我们都是自动分配的。所以我们不知道本机地址是什么？想知道自己的ip公网地址，可以通过百度搜索IP查看自己的ip位置

那么问题来了。百度是怎么知道我的公网IP的？

一般情况，用户访问我们的服务网络拓扑如下：

用户通过域名或者IP访问门户，然后请求到后端服务。这样的话后端服务就可以通过request.getRemoteAddr();方法获取用户的ip。

SpringBoot获取IP如下：

@RestController

public class IpController {

​

    @RequestMapping("/getIp")

    public String hello(HttpServletRequest request) {

        String ip = request.getRemoteAddr();

        System.out.println(ip);

        return ip;

    }

}

将服务部署到服务端，然后请求该接口,即可获取IP信息，如下图：

但是为什么我们获取的IP和百度搜出来的不一样呢？

1.1内网IP和外网IP

打开电脑CMD，输出ipconfig命令，查看本机的IP地址，发现我们本机地址和程序获取的地址是一样的。

其实，网络也是分内网IP和公网IP的。内网也成局域网。对于像公司，学校这种一般内部建立自己的局域网，对内部的信息进行传输时，都是通过内网相互通讯，建立局域网内网通讯节省了公网IP资源，并且通信效率也有很大的提升。当然非局域网内的设备则无法向内网的设备发送信息。

但是机器想要访问互联网的资源时，则需要机器拥有外网带宽，也就是我们所说的分配公网IP，负责也是无法访问互联网资源的。

因此，我们把服务部署在同一局域网内，客户端使用内网进行通信，因此获取的就是内网IP地址。但访问百度是需要使用公网访问，因此百度搜出来的IP就是公网IP地址。

1.2.为什么有时候获取到的客户端IP有问题?

当我们兴致勃勃的把IP获取的功能搞上去之后，发现获取的IP都是同一个？这是为什么呢？不可能只是一个用户在访问呀？查询IP信息之后发现，原来是我们部署的一台负载均衡的IP地址。

那么后端服务获取的地址都是负载均衡如nginx的地址。那么怎么透过负载均衡获取真实的地址呢？

透明的代理服务器在将客户端的访问请求转发到下一环节的服务器时，会在HTTP的请求头中添加一条X-Forwarded-For记录，用于记录客户端的IP，格式为X-Forwarded-For:客户端IP。如果客户端和服务器之间有多个代理服务器，则X-Forwarded-For记录使用以下格式记录客户端IP和依次经过的代理服务器IP：X-Forwarded-For:客户端IP, 代理服务器1的IP, 代理服务器2的IP, 代理服务器3的IP, ……。

因此，常见的Web应用服务器可以通过解析X-Forwarded-For记录获取客户端真实IP。

public static String getIp(HttpServletRequest request) {

    String ip = request.getHeader("x-forwarded-for");

​

    if (ip == null || ip.length() == 0 || "unknown".equalsIgnoreCase(ip)) {

        ip = request.getRemoteAddr();

    } else if (ip.length() > 15) {

        //多次反向代理后会有多个ip值，第一个ip才是真实ip

        String[] ips = ip.split(",");

        for (int index = 0; index < ips.length; index++) {

            String strIp = ips[index];

            ip = strIp;

            break;

        }

    }

    return ip;

}

第二步：如何解析IP

IP来了，我们怎么解析呢：

IP的解析一般都要借助第三方软件使用了，第三方一般也分为离线库和在线库

• 离线库支持的有如:IPIP，使用离线库的好处是解析效率高，性能好，问题就是IP库要经常更新。如果大家需要我私信我可以提供给大家比较新版本的ip库。


• 在线库则各大云厂商接口能力都有支持。在线版本的好处是更新即时，问题就是接口查询性能和使用TPS有要求。

以下演示借助IP库离线IP解析方式:

借助IP库就可以帮我们实现ip地址的解析。

public static void main(String[] args) {

    IpAddrInfo IpAddrInfo = IPAddr.getInstance().putLocInfo("114.103.71.226");

    System.out.println(JSONObject.toJSONString(IpAddrInfo));

}

​

public IpAddrInfo putLocInfo(String ip) {

    IpAddrInfo info = new IpAddrInfo();

    if (StringUtils.isNotBlank(ip)) {

        try {

            DistrictInfo addrInfo = db.findInfo(ip, "CN");

            info.setCity(addrInfo.getCityName());

            info.setCountry(addrInfo.getCountryName());

            info.setCountryCode(addrInfo.getChinaAdminCode());

            info.setIsp(addrInfo.getIsp());

            info.setLat(addrInfo.getLatitude());

            info.setLon(addrInfo.getLongitude());

            info.setProvince(addrInfo.getRegionName());

            info.setTimeZone(addrInfo.getTimeZone());

            System.out.println(addrInfo.toString());

        } catch (IPFormatException e) {

            e.printStackTrace();

        } catch (InvalidDatabaseException e) {

            e.printStackTrace();

        }

    }

    return info;

}

其实IP的定位解析其实就是一个巨大的位置库，同时IP数量也是有限制的，因此同一个Ip也可能会分配到不同的区域，因此影响IP解析位置准确率的有几个方面
1、位置库不精准，导致解析偏差大或者地区字段确实
2、离线库更新不及时
并且海外的一般有专门的离线库去支持，使用同一套离线库并不一定支持海外IP的解析，所以本次受影响最大的海外网红门被解析到中国各个地区，被大家认为造假，当然也包括真的有造假。不过上线了这个功能也是有好处的，至少网络不是法外之地，大家也要有序的健康的冲浪，拒绝网络暴力。

好了，今天就到这里，我是王老狮，一个有想法有内涵的工程狮，关注我，学习更多技术知识。

• 我正在参与掘金技术社区创作者签约计划招募活动，点击链接报名投稿
  作者：王老狮
  来源：juejin.cn/post/7118193660814393352
  a>。

大家好啊，又跟大家见面了，最近有个需求就是批量修改公司的数据报表，正式环境！！
而且要执行update！！

update it_xtgnyhcebg I set taskStatus = XXX

而且是没有加where条件的，相当于全表更新，这可马虎不得，我们在任何操作正式数据库之前一定一定要对数据库备份！！不要问我怎么知道的，因为我就因为有一次把测试环境的数据覆盖到正式环境去了。。。

别到时候就后悔莫及，那是没有用的！

由于这个需求是需要在跨库操作的，所以我们在查询数据的时候需要带上库的名称，例如这样

SELECT

	* 

FROM

	BPM00001.ACT_HI_PROCINST P 

	LEFT JOIN BPM00001.ACT_HI_VARINST V ON V.PROC_INST_ID_ = P.ID_ 

	AND V.NAME_ = '__RESULE'

这样如果我们在任何一个库里面，只要在一个mysql服务里面都可以访问到这个数据
查出这个表之后

我们需要根据这里的内容显示出不同的东西
就例如说是“APPROVAL”我就显示“已通过”
这就类似与java中的Switch，其实sql也能实现这样的效果
如下：

这就是sql的case语句的使用
有了这些数据之后我们就可以更新数据表了，回到我们之前讨论过的，这是及其危险的操作
我们先把要set的值给拿出来

但是我们怎么知道这个里面的主键呢？
你如果直接这么加，肯定是不行的

所以我们需要在sql后面加入这样的一条语句

注意，这个语句一定要写在set语句的里面，这样sql就能依据里面判断的条件进行一一赋值
最后，将这个sql语句执行到生产库中

拓展：

作为查询语句的key绝对不能重复，否则会失败（找bug找了半天的人的善意提醒）
例如上面的语句中P.BUSINESS_KEY_必须要保证是唯一的！！

成功执行！！！
怎么样，这些sql

分享工作中重要的经历，可以当小说来看

一、伪内存泄漏排查

1.1 背景

我们原来有一个刚用 C++ 写的业务服务，迟迟不敢上线，原因是内存泄漏问题一直解决不了。现象是，服务上线后，内存一直慢慢每隔几秒上涨4/8KB，直到服务下线。

我刚入职不久，领导让我来查这个问题，非常具有挑战性，也是领导对我的考察！

1.2 分析

心路历程1：工具分析

使用 Valgrind 跑 N 遍服务，结果中都没有发现内存泄漏，但是有很多没有被释放的内存和很多疑似内存泄漏。实在没有发现线索。

心路历程2：逐个模块排查

工具分析失败，那就挨个模块翻看代码，并且逐个模块写demo验证该模块是否有泄漏（挂 Valgrind），很遗憾，最后还是没有找到内存泄漏。

心路历程3：不抛弃不放弃

这个时候两周快过去了，领导说：“找不到内存泄漏那就先去干别的任务吧”，感觉到一丝凉意，我说：“再给我点时间，快找到了”。这样顶着巨大压力加班加点的跑Valgrind，拿多次数据结果进行对比，第一份跑 10 分钟，第二份跑 20 分钟，看看有哪些差异或异常，寻找蛛丝马迹。遗憾的是还是没有发现内存泄漏在哪。

功夫不负有心人，看了 N 份结果后，对一个队列产生了疑问，它为啥这么大，队列长度 1000 万，直觉告诉我，它不正常。

去代码中找这个队列，确实在初始化的时候设置了 1000 万长度，这个长度太大了。

1.3 定位

进队列需要把虚拟地址映射到物理地址，物理内存就会增加，但是出队列物理内存不会立刻回收，而是保留给程序一段时间（当系统内存紧张时会主动回收），目的是让程序再次使用之前的虚拟地址更快，不需要再次申请物理内存映射了，直接使用刚才要释放的物理内存即可。

当服务启动时，程序在这 1000 万队列上一直不停的进/出队列，有点像貔貅，光吃不拉，物理内存自然会一直涨，直到貔貅跑到了队尾，物理内存才会达到顶峰，开始处在一个平衡点。

图1 中，红色代表程序占用的物理内存，绿色为虚拟内存。

图1

然而每次上线还没等 到达平衡点前就下线了，担心服务内存一直涨，担心出事故就停服务了。解决办法就是把队列长度调小，最后调到了 2 万，再上线，貔貅很快跑到了队尾，达到了平衡点，内存就不再增涨。

其实，本来就没有内存泄漏，这就是伪内存泄漏。

二、周期性事故处理

2.1 背景

我们有一个业务，2019 年到 2020 年间发生四次（1025、0322、0511 和 0629）大流量事故，事故时网络流量理论峰值 3000 Gbps，导致网络运营商封禁入口 IP，造成几百万元经济损失，均没有找到具体原因，一开始怀疑是服务器受到网络攻击。

后来随着事故发生次数增加，发现事故发生时间具有规律性，越发感觉不像是被攻击，而是业务服务本身的流量瞬间增多导致。服务指标都是事故造成的结果，很难倒推出事故原因。

2.2 猜想（大胆假设）

2.2.1 发现事故大概每50天发生一次

清晰记得 2020 年 7 月 15 日那天巡检服务时，我把 snmp.xxx.InErrors 指标拉到一年的跨度，如图2 发现多个尖刺的间距似乎相等，然后我就看了下各个尖刺时间节点，记录下来，并且具体计算出各个尖刺间的间隔记录在下面表格中。着实吓了一跳，大概是 50 天一个周期。并且预测了 8月18日 可能还有一次事故。

图2 服务指标

2.2.2 联想50天与uint溢出有关

7 月 15 日下班的路上，我在想 3600（一个小时的秒数），86400（一天的秒数），50 天，5 x 8 等于 40，感觉好像和 42 亿有关系，那就是 uint（2^32），就往上面靠，怎么才能等于 42 亿，86400 x 50 x 1000 是 40 多亿，这不巧了嘛！拿出手机算了三个数：

2^32                  = 4294967296 

3600 * 24 * 49 * 1000 = 4233600000 

3600 * 24 * 50 * 1000 = 4320000000 

好巧，2^32 在后面的两个结果之间，4294967296 就是 49 天 16 小时多些，验证了大概每 50 天发生一次事故的猜想。

图3 联想过程

2.3 定位（小心求证）

2.3.1 翻看代码中与时间相关的函数

果然找到一个函数有问题，下面的代码，在 64 位系统上没有问题，但是在 32 位系统上会发生溢出截断，导致返回的时间是跳变的，不连续。图4 是该函数随时间输出的折线图，理想情况下是一条向上的蓝色直线，但是在 32 位系统上，结果却是跳变的红线。

uint64_t now_ms() {

    struct timeval t;

    gettimeofday(&t, NULL);

    return t.tv_sec * 1000  +  t.tv_usec / 1000;

}

图4 函数输出

这里解释一下，问题出在了 t.tv_sec * 1000，在 32 位系统上会发生溢出，高于 32 位的部分被截断，数据丢失。不幸的是我们的客户端有一部分是 32 位系统的。

2.3.2 找到出问题的逻辑

继续追踪使用上面函数的逻辑，发现一处问题，客户端和服务端的长链接需要发Ping保活，下一次发Ping时间等于上一次发Ping时间加上 30 秒，代码如下：

next_ping = now_ms() + 30000;

客户端主循环会不断判断当前时间是否大于 next_ping，当大于时发 Ping 保活，代码如下：

if (now_ms() > next_ping) {

    send_ping();

    next_ping = now_ms() + 30000;

}

那怎么就出现大流量打到服务器呢？举个例子，如图3，假如当前时间是 6月29日 20:14:00（20:14:26 时 now_ms 函数返回 0），now_ms 函数的返回值超级大。

那么 next_ping 等于 now_ms() 加上 30000（30s），结果会发生 uint64 溢出，反而变的很小，这就导致在接下来的 26 秒内，now_ms函数返回值一直大于 next_ping，就会不停发 Ping 包，产生了大量流量到服务端。

2.3.3 客户端实际验证

找到一个有问题的客户端设备，把它本地时间拨回 6月29日 20:13:00，让其自然跨过 20:14:26，发现客户端本地 log 中有大量发送 Ping 包日志，8 秒内发送 2 万多个包。证实事故原因就是这个函数造成的。解决办法是对 now_ms 函数做如下修改：

uint64_t now_ms() {

    struct timespec t;

    clock_gettime(CLOCK_MONOTONIC, &t);

    return uint64_t(t.tv_sec) * 1000  +  t.tv_nsec / 1000 / 1000;

}

2.3.4 精准预测后面事故时间点

因为客户端发版周期比较长，需要做好下次事故预案，及时处理事故，所以预测了后面多次事故。

2.4 总结

该事故的难点在于大部分服务端的指标都是事故导致的结果，并且大流量还没有到业务服务，就被网络运营商封禁了 IP；并且事故周期跨度大，50 天发生一次，发现规律比较困难。

发现规律是第一步，重点是能把 50 天和 uint32 的最大值联系起来，这一步是解决该问题的灵魂。

• 大胆假设：客户端和服务端的代码中与时间相关的函数有问题；


• 小心求证：找到有问题的函数，别写代码验证，最后通过复现定位问题；

经过不屑努力从没有头绪到逐渐缩小排查范围，最后定位和解决问题。

博主在浏览 medium 社区时，发现了一篇点赞量 1.5k 的文章，名称叫《Java is Dead — 5 Misconceptions of developers that still think Java is relevant today!》直译过来就是《Java 已死 — 开发人员对 Java 在现代编程语言中的5个误解》。这篇文章可以说是标题党得典范，热度全靠标题蹭 😂。当然本文重点在于文章评论区。作者因为标题党惨着评论区大佬们怒怼，不敢回复。

原文地址：medium.com/@sidh.thoma… Thomas

推荐博主开源的 H5 商城项目waynboot-mall，这是一套全部开源的微商城项目，包含三个项目：运营后台、H5 商城前台和服务端接口。实现了商城所需的首页展示、商品分类、商品详情、商品 sku、分词搜索、购物车、结算下单、支付宝/微信支付、收单评论以及完善的后台管理等一系列功能。 技术上基于最新得 Springboot3.0、jdk17，整合了 MySql、Redis、RabbitMQ、ElasticSearch 等常用中间件。分模块设计、简洁易维护，欢迎大家点个 star、关注博主。

github 地址：github.com/wayn111/way…

下面是文章内容：

人们仍然认为 Java 与当今时代相关，这是一种常见的误解。事实上 Java 是一种正在消亡的编程语言。 Java 一直是世界上使用最广泛、最流行的编程语言之一，但它很快就会面临消亡的危险。如今 Java 拥有庞大而活跃的开发者社区，并且仍然用于广泛的应用程序，包括 Web 开发、移动应用程序开发和企业级软件开发，但 Java 能在未来 10 年生存吗？让我们看看开发者对 Java 有哪些误解：

误解 1：Java 拥有庞大且活跃的开发者社区。世界各地有数百万 Java 开发人员，该语言在开发人员共享知识和资源的在线论坛和社区中占有重要地位。

虽然情况仍然如此，但开发人员转向其他平台和编程语言的速度很能说明问题，我个人也看到开发人员惊慌失措地跳槽。主要问题是 Java 作为一种编程语言还没有现代化，因此它仍然很冗长，通过一个步履蹒跚但极其笨重的类型系统结合了静态和动态类型之间最糟糕的两个世界，并且要求在具有以下功能的 VM 上运行宏观启动时间（对于长时间运行的服务器来说不是问题，但对于命令行应用程序来说是痛苦的）。虽然它现在表现得相当不错，但它仍然无法与 C 或 C++ 竞争，并且只要有一点爱，C#、Go、Rust 和 Python 就可以或将会在该领域超越它。对于现实世界的生产服务器，它往往需要大量的 JVM 调整，而且很难做到正确。

误解 2：Java 的应用范围很广。 Java 不仅仅是一种 Web 开发语言，还用于开发移动应用程序、游戏和企业级软件。这种多功能性使其成为许多不同类型项目的有价值的语言。

Java 不再是移动应用程序开发（尤其是 Android）首选的编程语言。 Kotlin 现在统治着 Android，大多数 Android 开发者很久以前就已经跳槽了。就连谷歌也因为几年前与甲骨文的惨败而放弃了 Java 作为 Android 的事实上的语言。 Java 作为一种 Web 开发语言也早已失去了它的受欢迎程度。就企业开发而言，Java 在大型企业中仍然适用，因为它可靠且稳定。尽管许多初创公司并未将 Java 作为企业软件的首选，但他们正在使用其他替代方案。

误解 3：Java 是基础语言。许多较新的编程语言都是基于 Java 的原理和概念构建的，并且旨在以某种方式与其兼容。这意味着即使 Java 的受欢迎程度下降，它的原理和概念仍然具有相关性。

虽然 Java 确实是许多人开始编程之旅的基础语言，但事实是 Java 仍然非常陈旧且不灵活。最重要的是，与其他现代编程语言相比，它仍然很冗长，这意味着它需要大量代码来完成某些任务。这会使编写简洁、优雅的代码变得更加困难，并且可能需要更多的精力来维护大型代码库。此外，Java 是静态类型的这一事实意味着它可能比动态类型语言更严格且灵活性较差，这可能会让一些开发人员感到沮丧。

误解 4：Java 得到各大公司的大力支持。 Oracle 是维护和支持 Java 的公司，对该语言有着坚定的承诺，并持续投资于其开发和改进。此外，包括 Google 和 Amazon 在内的许多大公司都在其产品和服务中使用 Java。

Oracle 的 Java 市场份额正在快速被竞争对手夺走。见下图：

尽管下图显示甲骨文仍然拥有最大的市场份额，但其份额已减少了一半以上。 2020 年，甲骨文占据了“大约 75% 的 Java 市场”，而现在的份额还不到 35%。

根据 New Relic 的数据，排名第二的是亚马逊，自 2021 年 11 月发布 Java 17 以来，其份额急剧上升，当时其份额几乎与 Eclipse Adoptium 相同。

误解 5：Java 在学校和大学中广泛教授。 Java 是一种流行的编程概念教学语言，经常用于学校和大学的计算机科学课程。这意味着有源源不断的新开发人员正在学习 Java 并熟悉其功能。

这种情况正在发生很大的变化。渴望成为软件开发人员的年轻大学生正在迅速转向其他编程语言。由于对这些其他编程语言的普遍需求，这越来越多地促使学院和大学寻找替代方案。

我知道这是一个有争议的话题。虽然我也认为 Java 是一种彻底改变了软件编写方式的语言，并为其他编程语言树立了可以效仿的基准。但不幸的是，该语言的所有权掌握在公司手中，在没有留下太多财务收益的情况下，该公司没有动力继续改进它。

OK，文章内容就这么多，下面是本文重点！

评论区

喜闻乐见评论区来了 😎，看看国外开发者怎么反驳这篇文章得，本文选取评论点赞量较高得5条评论放在下文。

评论一

作者不知道什么是编程语言、它为什么存在以及它在哪里使用。

仅因为许多程序员都在应用程序中最简单的部分工作，就认为 Java 与 Python 等效，这是完全错误的。

假设自因为使用自行车的人比驾驶采矿机的人多，我就认为自行车比卡特彼勒采矿机更好，这是不对得。

评论二

哈哈哈，我想说他甚至可能不是一个程序员，可能会做一些 JavaScript 的事情，即使如此，将 JavaScript 和 TypeScript 归类为两种语言也是没有意义的。

在安卓开发中，他不明白 Kotlin 是什么，虽然它确实有效。

评论三

每次看到这样的文章我都会直接去看评论。（喜闻乐见评论区🤔）

评论四

对于成熟，我有一些话要说。我过去三份工作中有两份是在一些公司开始使用一种性感的新语言（即 ruby 和 python），然后付钱给像我这样的人用 Java 重写他们的应用程序。

评论五

作者似乎不明白编程语言的风格是出于不同的目的而存在的，语言之间进行比较没有意义， 比如拿 sql 或 html/css 与 java 来比？语言是一个丰富的生态系统，我们需要为特定目的选择正确的语言。因此需要多语言开发人员而不是教条主义。

总结

博主这里说下自己得看法，虽然作者对于自己得观点进行了5个误解的阐述，但是博主是并不认同得。

• 文章的标题就是一个误导性的问题，暗示了 Java 已经不行。事实上 Java 仍然是一门非常流行和强大的编程语言，它在很多领域都有广泛的应用和优势，如移动应用、Web 应用、可穿戴设备、大数据、云计算等。Java 也有不断地更新和改进，引入了很多新的特性和功能，以适应不断变化的技术需求。


• Java 也有庞大的社区和丰富的资源，为开发者提供了很多支持和帮助。根据 GitHub Octoverse Report 2022，Java 是第三大最受欢迎的语言，仅次于 JavaScript、Python。根据 JetBrains State of Developer Ecosystem 2022，Java 是过去12个月内使用占有率排名第五的语言，占据了 48% 的份额。根据 StackOverflow Developer Survey 2022，最常用的编程语言排行榜中 Java 是排名第六的语言，占据了 33.27% 的份额。这些数据都表明 Java 并没有死亡或不在流行，而是仍然保持着其重要的地位。

• 文中说 Java 是一门过时和冗长的语言，它没有跟上时代的变化，而其他语言如 Python、JavaScript 和 Kotlin 等都更加简洁和现代化。这个观点忽略了 Java 的设计哲学和目标。Java 是一门成熟、稳定、跨平台、高性能、易维护、易扩展的编程语言，它注重可读性、健壮性和兼容性。Java 的语法可能相对复杂，但它也提供了很多强大的特性和功能，如泛型、注解、枚举、lambda 表达式、流 API、模块化系统等。


• Java 也没有停止创新和改进，它在近几年引入了很多新的特性和功能，如 Record 类、密封类、模式匹配、文本块、虚拟线程、外部函数和内存API等。其他语言可能在某些方面比 Java 更加简洁或现代化，但它们也有自己的局限和缺点，比如运行速度慢、类型系统弱、错误处理困难等。不同的语言适合不同的场景和需求，并不是说一种语言就可以完全取代另一种语言。

总之，我觉得 Java 在未来会被替代的可能性很小，但也不能掉以轻心，在后端开发领域，Go 已经在逐步蚕食 Java 得份额，今年非常火得 ai 模型领域相关，大部分代码也是基于 Python 编写。Java 需要在保持优势领域地位后持续地创新和改进。

关注公众号【waynblog】每周分享技术干货、开源项目、实战经验、高效开发工具等，您的关注将是我的更新动力！

作者：waynaqua
来源：juejin.cn/post/7252127579195736119

分布式协议一口气学完

一、Raft 协议

1.1 基础概念

Raft 算法是通过一切以领导者为准的方式，实现一系列数据的共识和各节点日志的一致。Raft是强领导模型，集群中只能有一个领导者。

成员身份：领导者（Leader）、跟随者（Follower）和候选者（Candidate）。

图1 成员身份

• 领导者：集群中霸道总裁，一切以我为准，处理写请求、管理日志复制和不断地发送心跳信息。


• 跟随者：普通成员，处理领导者发来的消息，发现领导者心跳超时，推荐自己成为候选人。


• 候选人：先给自己投一票，然后请求其他集群节点投票给自己，得票多者成为新的领导者。


• 任期编号：每任领导者都有任期编号。当领导者心跳超时，跟随者会变成候选人，任期编号 +1，然后发起投票。任期编号小的服从编号大的。


• 心跳超时：每个跟随者节点都设置了随机心跳超时时间，目的是避免跟随者们同时成为候选人，同时发起投票。


• 选举超时：每轮选举的结束时间，随机选举超时时间可以避免多个候选人同时结束选举未果，然后同时发起下一轮选举

1.2 领导选举

1.2.1 选举规则

• 领导者周期性地向跟随者发送心跳消息，告诉跟随者我是领导者，阻止跟随者发变成候选人发起新选举；


• 如果跟随者的随机心跳超时了，那么认为没有领导者了，推荐自己为候选人，发起新的选举；


• 在一轮选举中，赢得一半以上选票的候选人，即成为新的领导者；


• 在一轮选举中，每个节点对每个任期编号的选举只能投出一票，先来先服务原则；


• 日志完整性高（也就是最后一条日志项对应的任期编号值更大，索引号更大）的跟随者A拒绝给完整性低的候选人B投票，即使B的任期编号大；

1.2.2 选举动画

图2 初始选举

图3 领导者宕机/断网

图4 第一轮选举未果，发起第二轮选举

1.3 日志复制

日志项（Log Entry）：是一种数据格式，它主要包含索引值（Log index）、任期编号（Term）和 指令（Command）。

• 索引值：它是用来标识日志项的，是一个连续的、单调递增的整数值。


• 任期编号：创建这条日志项的领导者的任期编号。


• 指令：一条由客户端请求指定的、服务需要执行的指令。

图5 日志信息

1.3.1 日志复制动画

图6 简单日志复制

图7 复杂日志复制

1.3.2 日志恢复

每次选举出来的Leader一定包含在多数节点上最新的已经提交的日志，新的Leader将会覆盖其他节点上不一致的数据。

虽然新Leader一定包括上一个Term的Leader已提交(Committed)日志，但是可能也包含上一个Term的Leader的未提交(Uncommitted)日志。

这部分未提交日志需要转变为Committed，相对比较麻烦，需要考虑Leader多次切换且未完成日志恢复，需要保证最终提案是一致的、确定的，不然就会产生所谓的幽灵复现问题。

为了将上一个Term未提交的日志转为已提交，Raft算法要求Leader当选后立即追加一条Noop的特殊内部日志，并立即同步到其它节点，实现前面未提交日志全部隐式提交。

这样保证客户端不会读到未提交数据，因为只有Noop被大多数节点同意并提交了之后（这样可以连带往期日志一起同步），服务才会对外正常工作；

Noop日志本身是一个分界线，Noop之前的日志被提交，之后的日志将会被丢弃。Noop日志仅包含任期编号和日志索引值，没有指令。

日志“幽灵复现”的场景

图8

第一步，A是领导者，在本地记录4和5日志，并没有提交，然后挂了。

图9

第二步，由于B的日志索引值比C的大，B成为了领导者，仅把日志3同步给了C，然后挂了。

图10

第三步，A恢复了，并且成为了领导者，然后把未提交的日志4和5同步给了B和C（C在A成为了领导者之后、同步日志之前恢复了），然后ABC都提交了日志4和5，就这样原本客户端写失败的日志4和5复活了，进而客户端会读到其认为未提交的日志（实际上集群日志已提交）。

Noop解决日志复现

第一步，同上面一样。

第二步，由于B的日志索引值比C的大，B成为了领导者，这次不仅把日志3同步给了C，还记录了一个Noop日志，并且同步给了C。

图11

第三步，当A恢复了，想成为领导者，发现自己的日志任期编号和日志索引值都不是最大的，即使B挂了也还有C，A也就成为不了领导者，乖乖使用B的日志覆盖自己的日志。

1.4 成员变更

集群成员变更最大的风险是可能同时出现 2 个领导者。比如在成员变更时，节点 A、B 和 C 之间发生了分区错误，节点 A、B 组成旧集群（ABC）中的“大多数”。

而节点 C 和新节点 D、E 组成了新集群（ABCDE）的“大多数”，它们可能会选举出新的领导者（比如节点 C）。结果出现了同时存在 2 个领导者的情况。违反了Raft协议中领导者唯一性原则。

图12 集群（ABC）同时增加节点D和E

最初解决办法是联合共识（Joint Consensus），但实现起来难，后来 Raft 的作者就提出了一种改进后的方法，单节点变更（single-server changes）。

在正常情况下，旧集群的“大多数”和新集群的“大多数”都会有一个重叠的节点。

图13 集群（ABCD）增加新节点E

图14 集群（ABCDE）删除节点A

图15 集群（ABC）增加新节点D

图16 集群（ABCD）删除节点A

需要注意的是，在分区错误、节点故障等情况下，如果并发执行单节点变更，那么就可能出现一次单节点变更尚未完成，新的单节点变更又在执行，导致集群出现 2 个领导者的情况。

二、Gossip 协议

Gossip协议，顾名思义，就像流言蜚语一样，利用一种随机、带有传染性的方式，将信息传播到整个网络中，并在一定时间内，使得系统内的所有节点数据一致。Gossip其实是一种去中心化思路的分布式协议，解决信息在集群中的传播和最终一致性。

2.1 原理

Gossip协议的消息传播主要有两种：反熵（Anti-Entropy）和谣言传播（Rumor-Mongering）。

2.1.1 反熵：节点相对固定，节点数量不多，以固定概率传播所有的数据

每个节点周期性地随机选择其他节点，通过互相交换各自的所有数据来消除两者之间的差异，实现数据的最终一致性。反熵非常可靠，但每次节点两两交换各自的所有数据会带来非常大的通信负担，因此不会频繁使用。通过引入校验和等机制，可以降低需要对比的数据量和传播消息量。

反熵 使用“simple epidemics”方式，其包含两种状态：susceptible和infective，这种模型也称为SI model。处于infective状态的节点代表其有数据更新，并且会将这个数据分享给其他节点；处于susceptible状态的节点代表其并没有收到来自其他节点的更新。

图17 反熵

2.2.2 谣言传播：节点动态变化，节点数量较多，仅传播新到达的数据

当一个节点有了新信息后，这个节点变成活跃状态，并周期性地向其他节点传播新信息。直到所有的节点都知道该新信息。由于节点之间只传播新信息，所以大大减少了通信负担。

谣言传播 使用“complex epidemics”方法，比反熵 多了一种状态：removed，这种模型也称为SIR model。处于removed状态的节点说明其已经接收到来自其他节点的更新，但是其并不会将这个更新分享给其他节点。因为谣言消息会在某个时间标记为removed，然后不会再被传播给其他节点，所以谣言传播有极小概率使得所有节点数据不一致。

图18 谣言传播

一般来说，为了在通信代价和可靠性之间取得折中，需要将这两种方法结合使用。

2.2 通信方式

节点间的交互主要有三种方式：推、拉和推/拉

图19 节点状态

2.2.1 推送模式（push）

节点A随机选择联系节点B，并向其发送自己的信息，节点B在收到信息后比较/更新自己的数据。

图20 推方式

2.2.2 拉取模式（pull）

节点A随机选择联系节点B，从对方获取信息，节点A在收到信息后比较/更新自己的数据。

图21 拉方式

2.2.3 推/拉模式（push/pull）

节点A向选择的节点B发送信息，同时从对方获取信息，节点A和节点B在收到信息后各自比较/更新自己的数据。

图22 推/拉方式

2.3 优缺点

• 优点
  
  
  
  • 可扩展性（Scalable）: Gossip协议是可扩展的，一般需要 O(logN) 轮就可以将信息传播到所有的节点，其中N代表节点的个数。每个节点仅发送固定数量的消息，并且与网络中节点数目无关。在数据传送时，节点并不会等待消息的Ack，所以消息传送失败也没有关系，因为可以通过其他节点将消息传递给之前传送失败的节点。允许节点的任意增加和减少，新增节点的数据最终会与其他节点一致。
  
  
  • 容错（Fault-tolerance）: 网络中任何节点的重启或者宕机都不会影响 Gossip 消息的传播，具有天然的分布式系统容错特性。
  
  
  • 健壮性（Robust）: Gossip协议是去中心化的协议，集群中的所有节点都是对等的，没有特殊的节点，所以任何节点出现问题都不会阻止其他节点继续发送消息。任何节点都可以随时加入或离开，而不会影响系统的整体服务质量。
  
  
  • 最终一致性（Convergent consistency）: Gossip协议实现信息指数级的快速传播，因此在有新信息需要传播时，消息可以快速地发送到全局节点，在有限的时间内能够做到所有节点都拥有最新的数据。
  
  
  
  


• 缺点
  
  
  
  • 消息延迟：节点随机向少数几个节点发送消息，消息最终是通过多个轮次的散播而到达全网，不可避免的造成消息延迟。
  
  
  • 消息冗余：节点定期随机选择周围节点发送消息，而收到消息的节点也会重复该步骤，不可避免地引起同一节点消息多次接收，增加消息处理压力。
  
  
  
  

三、参考

• raft.github.io


• thesecretlivesofdata.com/raft/


• Raft算法（一）：如何选举领导者？


• Raft算法（二）：如何复制日志？


• Raft算法（三）：如何解决成员变更的问题？


• 如何解决分布式系统中的“幽灵复现”？


• Gossip协议：流言蜚语，原来也可以实现一致性


• 浅谈集群版Redis和Gossip协议，它们之间的联系及用法


• 分布式一致协议Gossip协议


• 分布式原理：一文了解 Gossip 协议


• 从Ping-Pong消息学习Gossip协议的实现

在Java中，可以使用多种方法生成唯一的ID。下面我将介绍几种常用的方法：

1. 
   

   UUID（Universally Unique Identifier）：UUID是一种128位的唯一标识符。它可以通过java.util.UUID类来生成，使用UUID.randomUUID()方法返回一个新的UUID。UUID的生成是基于时间戳和计算机MAC地址等信息，因此几乎可以保证全局唯一性。

   
   

   import java.util.UUID;
   
   
   
   public class UniqueIdExample {
   
       public static void main(String[] args) {
   
           UUID uuid = UUID.randomUUID();
   
           String id = uuid.toString();
   
           System.out.println(id);
   
       }
   
   }
   
   

   
   


2. 
   

   时间戳：可以使用当前时间戳作为唯一ID。使用System.currentTimeMillis()方法可以获取当前时间的毫秒数作为ID值。需要注意的是，时间戳只是在同一台机器上保持唯一性，在分布式系统中可能存在重复的风险。

   
   

   public class UniqueIdExample {
   
       public static void main(String[] args) {
   
           long timestamp = System.currentTimeMillis();
   
           String id = String.valueOf(timestamp);
   
           System.out.println(id);
   
       }
   
   }
   
   

   
   


3. 
   

   Snowflake算法：Snowflake是Twitter开源的一种分布式ID生成算法，可以生成带有时间戳、机器ID和序列号的唯一ID。可以使用第三方库（如Twitter的Snowflake）来生成Snowflake ID。Snowflake ID的生成是基于时间序列、数据中心ID和机器ID等参数的。

   
   

   import com.twitter.snowflake.SnowflakeIdGenerator;
   
   
   
   public class UniqueIdExample {
   
       public static void main(String[] args) {
   
           SnowflakeIdGenerator idGenerator = new SnowflakeIdGenerator();
   
           long id = idGenerator.nextId();
   
           System.out.println(id);
   
       }
   
   }
   
   

   
   

以上是一些常用的生成唯一ID的方法，每种方法都有自己的特点和适用场景。选择合适的方法要根据具体需求、性能要求

简单的 HTTP 协议本身并不存在安全性问题,因此协议本身几乎不会成为攻击的对象。应用 HTTP 协议的服务器和客户端,已经运行在服务器上的 Web 应用等资源才是攻击目标。

在客户端即可篡改请求

在 Web 应用中,从浏览器那接收到的 HTTP 请求的全部内容,都可以在客户端自由地变更、篡改。所以 Web 应用可能会接收到与预期数据不相同的内容。

在 HTTP 请求报文内加载攻击代码,就能立发起对 Web 应用的攻击,通过 URL 查询字段或表单、HTTP 首部、Cookie 等途径吧攻击代码传入,若这时 Web 应用存在安全漏洞,那内部信息就会遭到窃取,或被攻击者拿到管理权限。

针对 Web 应用的攻击模式

对 Web 应用的攻击模式有以下两种:

• 主动攻击;


• 被动攻击;

以服务器为目标的主动攻击

主动攻击是指攻击者通过直接访问 Web 应用,把攻击代码传入的模式,由于该模式是直接针对服务器上的资源进行攻击,因此攻击者能够访问到那些资源。

主动攻击模式里面具有代表性的攻击是 SQL 注入攻击和 OS 命令注入攻击。

以服务器为目标的被动攻击

被动攻击是指利用圈套策略执行攻击代码的攻击模式,在被动攻击过程中,攻击者不直接对目标 Web 应用访问发起攻击。

被动攻击通常的攻击模式如下所示:

1. 攻击者诱使用户触发已设置好的陷阱,而陷阱会启动发送已嵌入攻击代码的 HTTP 请求;


2. 当用户不知不觉中招之后,用户的浏览器或邮件客户端会触发这个陷阱;


3. 中招后的用户浏览器会把含有攻击代码的 HTTP 请求发送给作为攻击目标的 Web 应用,运行攻击代码;


4. 执行完攻击代码，存在安全漏洞的 Web 应用会成为攻击者的跳板,可能导致用户所持的 Cookie 等个人信息被窃取,登录状态中的用户权限遭恶意滥用等后果。

被动攻击模式中具有代表性的攻击是跨站脚本攻击和跨站点请求伪造。

利用被动攻击,可发起对原本从互联网上无法直接访问的企业内网等网络的攻击。只要用户踏入攻击者预先设好的陷阱,在用户能够访问到的网络范围内,即使是企业内网也同样会受到攻击。

因输出值转移不完全引发的安全漏洞

实施 Web 应用的安全对策可大致分为以下两部分:

• 客户端的验证;


• Web 应用端的验证:
  
  
  
  • 输入值验证;
  
  
  • 输出值转义;
  
  
  
  

因为 JavaScript 代码可以在客户端随便修改或者删除,所以不适合将 JavaScript 验证作为安全的方法策略。保留客户端验证只是为了尽早地辨识输入错误,起到提高 UI 体验的作用。

输入值验证通常是指检查是否是符合系统业务逻辑的数值或检查字符编码等预防对策。

从数据库或文件系统、HTML、邮件等输出 Web 应用处理的数据之际,针对输出做值转义处理是一项至关重要的安全策略。当输出值转义不完全时,会因触发攻击者传入的攻击代码,而给输出对象带来损害。

跨站脚本攻击

跨站脚本攻击(Cross-Site Scripting,XSS)是指通过存在安全漏洞的 Web 网站注册用户的浏览器内运行非法的 HTML 标签或 JavaScript 进行的一种攻击。动态创建的 HTML 部分有可能隐藏这安全漏洞。就这样,攻击者编写脚本设下陷阱,用户在自己的浏览器上运行时,一不小心就会受到被动攻击。

跨站脚本攻击有可能造成一下影响:

• 利用虚假输入表单骗取用户个人信息;


• 利用脚本窃取用户的 Cookie 值,被害者在不知情的情况下,帮助攻击者发送恶意请求;


• 显示伪造的文章或图片;

跨站脚本攻击案例

在动态生成 HTML 处发生

下面以编辑个人信息页面为例讲解跨站脚本攻击,下放界面显示了用户输入的个人信息内容:

确认姐妹按原样显示在编辑解密输入的字符串。此处输入带有山口伊朗这样的 HTML 标签的字符串。

那如果我把输入的内容换成一段 JavaScript 代码呢,阁下又该如何应对?

<script>

  alert("落霞与孤鹜齐飞,秋水共长天一色!");

</script>

XSS 是攻击者利用预先设置的陷阱触发的被动攻击

跨站脚本攻击属于被动攻击模式,因此攻击者会事先布置好用于攻击的陷阱。

下图网站通过地址栏中 URI 的查询字段指定 ID,即相当于在表单内自动填写字符串的功能。而就在这个地方,隐藏着可执行跨站脚本攻击的漏洞。

充分熟知此处漏洞特点的攻击者,于是就创建了下面这段嵌入恶意代码的 URL。并隐藏植入事先准备好的欺诈邮件中或 Web 页面内,诱使用户去点击该 URL。

浏览器打开该 URI 后,直观感觉没有发生任何变化,但设置好的脚本却偷偷开始运行了。当用户在表单内输入 ID 和密码之后,就会直接发送到攻击者的网站,导致个人登录信息被窃取。

之后,ID 及密码会传给该正规网站,而接下来仍然是按正常登录步骤,用户很难意识到自己的登录信息已遭泄露。

除了在表单中设下圈套之外,下面那种恶意构造的脚本统一能够通过跨站脚本攻击的方式,窃取到用户的
Cookie 信息:

const cookie = document.cookie;

执行上面这段 JavaScript 程序,即可访问到该 Web 应用所处域名下的 Cookie 信息,然后这些信息会发送至攻击者的 Web 网站,记录在它的登录日志中,攻击者就这样窃取到用户的 cookie 信息了。

React 中通过 JSX 语法转义来防止 XSS。在 JSX 语法中,可以通过花括号 {} 插入 JavaScript 表达式。JSX 语法会自动转义被插入到 HTML 标签之间的内容。这意味着任何用户输入的内容都会被转义,以防止恶意脚本的执行。在转义过程中,React 会将特殊字符进行转换,例如将小于号 < 转义为 <、大于号 > 转义为 >、引号 " 转义为 " 等。这样可以确保在渲染时,用户输入的内容被当作纯文本处理,而不会被解析为 HTML 标签或 JavaScript 代码。

SQL 注入攻击

会执行非法 SQL 的 SQL 注入攻击

SQL 注入是指针对 Web 应用使用的数据库,通过运行非法的 SQL 而产生的攻击。该安全隐患有可能引发极大的威胁,有时会直接导致个人信息及机密信息的泄露。

SQL 注入攻击有可能会造成以下等影响:

• 非法查看或篡改数据库内的数据;


• 规避认证;


• 执行和数据库服务器业务关联的程序等;

SQL 注入攻击案例

• 登录绕过攻击: 攻击者可以在登录表单的用户名和密码字段中插入恶意的 SQL 代码。如果应用程序未对输入进行正确的验证和过滤,攻击者可以通过在用户名字段中输入 ' OR '1'='1 的恶意输入来绕过登录验证,使得 SQL 语句变为：SELECT \* FROM users WHERE username = '' OR '1'='1' AND password = '<输入的密码>'，从而成功登录到系统中;


• 删除或修改数据攻击: 攻击者可以通过注入恶意的 SQL 代码来删除或修改数据库中的数据。例如,攻击者可以在一个表单的输入字段中插入 '; DROP TABLE users;-- 的恶意输入。如果应用程序未正确处理这个输入,攻击者可以成功删除用户表(假设表名为 "users")导致数据丢失;

OS 命令注入攻击

OS 命令注入攻击是指通过 Web 应用,执行非法的操作系统命令达到攻击的目的。只要在能调用 Shell 函数的地方就有存在被攻击的风险。

可以从 Web 应用中通过 Shell 来调用操作系统命令,如果调用 Shell 是存在疏漏,就可以执行插入的非法 OS 命令。

OS 命令注入攻击可以向 Shell 发送命令,让 Windows 或 Linux 操作系统的命令行启动程序。也就是说,通过 OS 注入攻击可执行 OS 上安装着的各种程序。

OS 注入攻击案例

• 文件操作攻击: 攻击者可以在应用程序的输入字段中插入恶意的操作系统命令来执行文件操作。例如,如果应用程序在文件上传过程中未对输入进行适当的验证和过滤,攻击者可以在文件名字段中插入 '; rm -rf / ;-- 的恶意输入。如果应用程序在执行文件操作时没有正确处理这个输入,攻击者可能会删除服务器上的所有文件;


• 远程命令执行攻击: 攻击者可以通过注入恶意的操作系统命令来执行远程系统命令。例如,如果应用程序在一个输入字段中插入 ; ping <恶意 IP 地址> ; 的恶意输入,而没有进行正确的输入验证和过滤,攻击者可以利用该注入漏洞执行远程命令,对目标系统进行攻击或探测;

HTTP 首部注入攻击

HTTP 首部注入攻击是指攻击者通过在响应首部字段内插入换行,添加任意响应首部或主体的一种攻击。属于被动攻击模式。

HTTP 首部注入攻击有可能造成以下一些影响:

• 设置任何 Cookie 信息;


• 重定向值任意 URL;


• 显示任意的主体;

HTTP 首部注入攻击案例

以下是一些 HTTP 首部注入攻击的案例,展示了攻击者是如何利用该漏洞进行攻击的:

• 重定向攻击: 攻击者可以在 HTTP 响应的 Location 首部中插入恶意 URL,从而将用户重定向到恶意网站或欺骗性的页面。如果应用程序未正确验证和过滤用户输入,并将其直接用作 Location 首部的值,攻击者可以在 URL 中插入换行符和其他特殊字符,添加额外的首部字段,导致用户被重定向到意外的位置;


• 缓存投毒攻击: 攻击者可以在 HTTP 响应的 Cache-Control 或其他缓存相关首部中插入恶意指令,以欺骗缓存服务器或浏览器,导致缓存数据的污染或泄漏。攻击者可以通过注入换行符等特殊字符来添加额外的首部字段或修改缓存指令,绕过缓存机制或引发信息泄露;


• HTTP 劫持攻击: 攻击者可以在 HTTP 响应的 Location 或 Refresh 首部中插入恶意 URL,将用户重定向到恶意网站或欺骗性页面,从而劫持用户的会话或执行其他攻击。通过在响应中插入恶意的 Location 或 Refresh 值,攻击者可以修改用户的浏览器行为;


• XSS 攻击: 攻击者可以在 HTTP 响应的 Set-Cookie 或其他首部字段中插入恶意脚本,以执行跨站脚本攻击。如果应用程序未正确过滤和转义用户输入,并将其插入到首部字段中,攻击者可以通过注入恶意代码来窃取用户的会话标识符或执行其他恶意操作;

因会话管理疏忽引发的安全漏洞

会话管理是用来管理用户状态的必备功能,但是如果在会话管理上有所疏忽,就会导致用户的认证状态被窃取等后果。

会话劫持

会话劫持是指攻击者通过某种手段拿到了用户的会话 ID,并非法使用此会话 ID 伪装成用户,达到攻击的目的:

具备人中功能的 Web 应用,使用会话 ID 的会话管理机制,作为管理认证状态的主流方式。会话 ID 中记录客户端的 Cookie 等信息,服务端将会话 ID 与认证状态进行一对一匹配管理。

下面列举了几种攻击者可获得会话 ID 的途径:

• 通过非正规的生成方法推测会话 ID;


• 通过窃听或 XSS 攻击盗取会话 ID;


• 通过会话固定攻击强行获取会话 ID;

会话劫持攻击案例

下面我们以认证功能为例讲解会话劫持。这里的认证功能通过会话管理机制，会将成功认证的用户的会话 ID,保存在用户浏览器的 Cookie 中。

攻击者在得知该 Web 网站存在可跨站攻击的安全漏洞后,就设置好用 JavaScript 调用 document.cookie 以窃取 cookie 信息的陷阱,一旦用户踏入陷阱访问了该脚本,攻击者就能获取含有会话的 ID 的 Cookie。

攻击者拿到用户的会话 ID 后,往自己的浏览器的 Cookie 中设置该会话 ID,即可伪装成会话 ID 遭窃的用户,访问 Web 网站了。

会话固定攻击

对一切去目标会话 ID 为主动攻击手段的会话劫持而言,会话固定攻击 攻击会强制用户使用指定的会话 ID,属于被动攻击。

会话固定攻击案例

下面我们以认证功能为例讲解会话固定攻击,这个 Web 网站的认证功能,会在认证前发布一个会话 ID,若认证成功,就会在服务器内改变认证状态。

攻击者准备陷阱,先访问 Web 网站拿到会话 ID,此刻,会话 ID 在服务器上的记录仪仍是未认证状态。

攻击者设计好强制用户使用该会话 ID 的陷阱,并等待用户拿着这个会话 ID 前去认证,一旦用户触发陷阱并完成认证,会话 ID 服务器上的状态(用户 A 已认证) 就会被记录下来。

攻击者估计用户差不多已触发陷阱后,再利用之前这个会话 ID 访问网站,由于该会话 ID 目前已是用户 A 已认证状态,于是攻击者作为用户 A 的身份顺利登陆网站。

会话固定攻击预防措施

会话固定攻击利用了应用程序在身份验证和会话管理过程中未正确处理会话标识符的漏洞。为了防止会话固定攻击,开发人员可以采取以下措施:

1. 生成随机、唯一的会话标识符,并在用户每次登录或创建新会话时重新生成;


2. 不接受用户提供的会话标识符,而是通过服务器生成并返回给客户端;


3. 在身份验证之前和之后,对会话标识符进行适当的验证和验证机制;


4. 设置会话管理策略,包括会话超时时间和注销会话的方式;

通过采取这些预防措施,可以减少会话固定攻击的风险,并提高应用程序的安全性。

跨站点请求伪造

跨站点伪造请求(Cross-Site Require Forgeries,CSRF)攻击是指攻击者通过设置好的陷阱,强制用户对已完成认证的用户进行非预期的个人信息或设定信息等某些状态更新,属于被动攻击。

跨站点请求伪造有可能会造成一下等影响:

• 利用已通过认证的用户权限更新设定信息等;


• 利用已通过认证的用户权限购买商品;


• 利用已通过认证的用户权限在评论区发表言论;

跨站点伪造请求的攻击案例

下面以一个网站的登录访问功能为例,讲解跨站点请求伪造,如下图所示:

1. 当用户输入账号信息请求登录 A 网站;


2. A 网站验证用户信息,通过验证后返回给用户一个 cookie;


3. 在未退出网站 A 之前,在同一浏览器中请求了黑客构造的恶意网站 B;


4. B 网站收到用户请求后返回攻击性代码,构造访问 A 网站的语句;


5. 浏览器收到攻击性代码后,在用户不知情的情况下携带 cookie 信息请求了 A 网站。此时 A 网站不知道这是由 B 发起的。那么这时黑客就可以为所欲为了!!!

这首先必须瞒住两个条件:

• 用户访问站点 A 并产生了 Cookie;


• 用户没有退出 A 网站同时访问了 B 网站;

CSRF 攻击的防御

当涉及到跨站伪造请求的防御时,一下是一些防御方法和实践:

1. 
   

   验证来源和引用检查:

   
   
   
   
   • 服务器端应该验证每个请求的来源 Referer 字段和源 Origin 字段以确保请求来自预期的域名或网站。如果来源不匹配,服务器应该拒绝请求。Referer 头部并不是 100% 可靠,因为某些浏览器或网络代理可能会禁用或篡改该字段。因此,Origin 字段被认为是更可靠的验证来源的方式;
   
   
   
   


2. 
   

   CSRF Token:

   
   

   
   

   CSRF 令牌是一个随机生成的值,嵌入到表单或请求参数中,与用户会话相关联。它的目的是验证请求的合法性,确保请求是由预期的用户发起的,而不是由攻击者伪造的。

   
   

   
   
   
   
   • 在每个表单和敏感操作的请求中,包括一个 CSRF 令牌;
   
   
   • 令牌可以作为隐藏字段 input type="hidden" 或请求头,例如 X-CSRF-Token 的一部分发送;
   
   
   • 在服务器端,验证请求中的令牌是否与用户会话中的令牌匹配,以确保请求的合法性;
   
   
   
   


3. 
   

   验证请求的方法: 某些敏感操作应该使用 POST、PUT 或 DELETE 等非幂等方法,而不是 GET 请求。这样可以防止攻击者通过构造图片或链接等 GET 请求来触发敏感操作;

   
   


4. 
   

   敏感操作的二次确认: 对于一些敏感操作,例如修改密码、删除账户等,可以在用户执行操作前要求二次确认,以确保用户的意图和授权;

   
   

综合采取上述防御措施,可以有效减少跨站伪造请求攻击的风险。然而,没有单一的解决方案可以完全消除跨站伪造请求的威胁,因此建议在开发过程中将安全性作为一个关键考虑因素,并进行全面的安全测试和审查。

参考文献

书籍: 图解HTTP

总结

没有总结,总结个屁,不上网就是

密码破解，是黑客们最喜欢的玩具之一。当你用“123456”这类简单密码来保护你的账户时，就像裸奔一样，等待着黑客的攻击。所以，今天我们就来聊聊密码破解知识，看看那些常见的密码破解方法，以及如何防范它们。

1、暴力破解

首先，我们来介绍一下最简单、最暴力的密码破解方法——暴力破解。

什么是暴力破解密码呢？

简单来说，就是 攻击者通过穷举所有可能的密码组合来尝试猜测用户的密码。如果你的密码太简单或者密码空间较小，那么暴力破解密码的成功几率会增加。

暴力破解密码的一般步骤：

step1：确定密码空间

密码空间是指所有可能的密码组合。密码空间的大小取决于密码的长度和使用的字符集。例如，对于一个只包含数字的4位密码，密码空间就是从0000到9999的所有组合。

step2：逐个尝试密码

攻击者使用自动化程序对密码空间中的每个密码进行逐个尝试。这可以通过编写脚本或使用专门的密码破解工具来实现。攻击者从密码空间中选择一个密码并将其用作尝试的密码。

step3：比对结果

对于每个尝试的密码，攻击者将其输入到目标账户进行验证。如果密码正确，那么攻击者成功破解了密码。否则，攻击者将继续尝试下一个密码，直到找到匹配的密码为止。

那么我们该如何防范暴力破解呢？

方案1：增强密码策略

增强密码策略，即选择强密码。强密码应该包括足够的长度、复杂的字符组合和随机性，以增加密码空间的大小，从而增加破解的难度。比如说，“K3v!n@1234”这样的密码就比“123456”要强得多。

方案2：登录尝试限制

限制登录尝试次数，例如设置最大尝试次数和锁定账户的时间。

方案3：双因素身份验证

我们还可以引入双因素身份验证，要求用户提供额外的验证信息，如验证码、指纹或硬件令牌等。

通过综合使用这些安全措施，我们可以大大减少暴力破解密码的成功几率，并提高账户和系统的安全性。

2、彩虹表攻击

接下来，我们来介绍一种更加高级、更加可怕的密码破解方法——彩虹表攻击。

彩虹表攻击是一种 基于预先计算出的哈希值与明文密码对应关系的攻击方式。

攻击者通过预先计算出所有可能的哈希值与对应的明文密码，并将其存储在一个巨大的“彩虹表”中。

当需要破解某个哈希值时，攻击者只需要在彩虹表中查找对应的明文密码即可。

攻击者生成彩虹表时需要耗费大量的计算和存储资源，但一旦生成完成，后续的密码破解速度就会非常快。

彩虹表攻击的基本原理如下：

step1：生成彩虹表

攻击者事先生成一张巨大的彩虹表，其中包含了输入密码的哈希值和对应的原始密码。彩虹表由一系列链条组成，每个链条包含一个起始密码和相应的哈希值。生成彩虹表的过程是耗时的，但一旦生成完成，后续的破解过程会变得非常快速。

step2：寻找匹配

当攻击者获取到被保护的密码哈希值时，他们会在彩虹表中搜索匹配的哈希值。如果找到匹配，就意味着找到了原始密码。

step3：链表查找

如果在彩虹表中没有找到直接匹配的哈希值，攻击者将使用哈希值在彩虹表中进行一系列的链表查找。他们会在链表上依次应用一系列的哈希函数和反向函数，直到找到匹配的密码。

那如何防范呢？

方案1：盐值（Salt）

使用随机盐值对密码进行加密。盐值是一个随机的字符串，附加到密码上，使得每次生成的哈希值都不同。这样即使相同的密码使用不同的盐值生成哈希，也会得到不同的结果，使得彩虹表无效。

方案2：迭代哈希函数

多次迭代哈希函数是指对原始密码进行多次连续的哈希运算的过程。

通常情况下，单次哈希函数的计算速度是相当快的，但它可能容易受到彩虹表等预先计算的攻击。为了增加密码的破解难度，我们可以通过多次迭代哈希函数来加强密码的安全性。

在多次迭代哈希函数中，原始密码会被重复输入到哈希函数中进行计算。每次哈希运算的结果会作为下一次的输入，形成一个连续的链式计算过程。例如，假设初始密码为 "password"，哈希函数为 SHA-256，我们可以进行如下的多次迭代哈希计算：

1. 首先，将初始密码 "password" 输入 SHA-256 哈希函数中，得到哈希值 H1。


2. 将哈希值 H1 再次输入 SHA-256 哈希函数中，得到哈希值 H2。


3. 将哈希值 H2 再次输入 SHA-256 哈希函数中，得到哈希值 H3。


4. 以此类推，进行多次迭代。

通过多次迭代哈希函数，我们可以增加密码破解的难度。攻击者需要对每一次迭代都进行大量的计算，从而大大增加了密码破解所需的时间和资源成本。同时，多次迭代哈希函数也提供了更高的密码强度，即使原始密码较为简单，其哈希值也会变得复杂和难以预测。

需要注意的是，多次迭代哈希函数的次数应根据具体的安全需求进行选择。次数过少可能仍然容易受到彩虹表攻击，而次数过多可能会对系统性能产生负面影响。因此，需要在安全性和性能之间进行权衡，并选择适当的迭代次数。

方案3：长度和复杂性要求

要求用户选择强密码，包括足够的长度、复杂的字符组合和随机性，以增加彩虹表的大小和密码破解的难度。

3、字典攻击

最后，我们来介绍一种基于字典的密码破解方法——字典攻击。

字典攻击是 通过使用一个包含常见单词和密码组合的字典文件来尝试破解密码（这文件就是我们常说的字典）。这种方法比暴力破解要高效得多，因为它可以根据常见密码和单词来进行尝试。

如果你使用了常见单词或者简单密码作为密码，那么字典攻击很有可能会成功。

以下是字典攻击的一般步骤：

step1：收集密码字典

攻击者会收集各种常见密码、常用字词、常见姓名、日期、数字序列等组成的密码字典。字典可以是公开的密码列表、泄露的密码数据库或通过爬取互联网等方式获得。

step2：构建哈希表

攻击者会对密码字典中的每个密码进行哈希运算，并将明文密码与对应的哈希值构建成一个哈希表，方便后续的比对操作。

step3：逐个比对

攻击者使用字典中的密码与目标账户的密码进行逐个比对。对于每个密码，攻击者将其进行哈希运算，并与目标账户存储的哈希值进行比较。如果找到匹配的哈希值，那么密码就被破解成功。

字典攻击的成功取决于密码的强度和字典的质量。

如果用户使用弱密码或常见密码，很容易受到字典攻击的威胁。为了抵御字典攻击，用户应该选择强密码，包括使用足够的长度、复杂的字符组合和随机性，以增加密码的猜测难度。而系统设计者可以使用前文介绍的方式来防止密码被破解，如密码加盐和限制登录尝试次数等。

好啦，今天的分享就到这里啦！希望大家都能保护好自己的账户安全，不要成

布隆过滤器（Bloom Filter）是一种用于快速判断一个元素是否属于某个集合的概率型数据结构。它基于哈希函数和位数组实现，可以高效地检索一个元素是否存在，但不提供元素具体的存储和获取功能。

布隆过滤器原理

上面的思路其实就是布隆过滤器的思想，只不过因为 hash 函数的限制，多个字符串很可能会 hash 成一个值。为了解决这个问题，布隆过滤器引入多个 hash 函数来降低误判率。

下图表示有三个 hash 函数，比如一个集合中有 x，y，z 三个元素，分别用三个 hash 函数映射到二进制序列的某些位上，假设我们判断 w 是否在集合中，同样用三个 hash 函数来映射，结果发现取得的结果不全为 1，则表示 w 不在集合里面。

布隆过滤器处理流程

布隆过滤器应用很广泛，比如垃圾邮件过滤，爬虫的 url 过滤，防止缓存击穿等等。下面就来说说布隆过滤器的一个完整流程，相信读者看到这里应该能明白布隆过滤器是怎样工作的。

第一步：开辟空间

开辟一个长度为 m 的位数组（或者称二进制向量），这个不同的语言有不同的实现方式，甚至你可以用文件来实现。

第二步：寻找 hash 函数

获取几个 hash 函数，前辈们已经发明了很多运行良好的 hash 函数，比如 BKDRHash，JSHash，RSHash 等等。这些 hash 函数我们直接获取就可以了。

第三步：写入数据

将所需要判断的内容经过这些 hash 函数计算，得到几个值，比如用 3 个 hash 函数，得到值分别是 1000，2000，3000。之后设置 m 位数组的第 1000，2000，3000 位的值位二进制 1。

第四步：判断

接下来就可以判断一个新的内容是不是在我们的集合中。判断的流程和写入的流程是一致的。

在PHP中如何使用？

在PHP中，可以使用BloomFilter扩展库或自行实现布隆过滤器。下面我将介绍两种方法。

1. 使用BloomFilter扩展库：

PHP中有一些第三方扩展库提供了布隆过滤器的功能。其中比较常用的是phpbloomd扩展，它提供了对布隆过滤器的支持。你可以按照该扩展库的文档进行安装和使用。

示例代码如下：

// 创建一个布隆过滤器

$filter = new BloomFilter();



// 向过滤器添加元素

$filter->add("element1");

$filter->add("element2");

$filter->add("element3");



// 检查元素是否存在于过滤器中

if ($filter->has("element1")) {

    echo "Element 1 may exist.";

} else {

    echo "Element 1 does not exist.";

}

2. 自行实现布隆过滤器：

如果你不想使用第三方扩展库，也可以自行实现布隆过滤器。下面是一个简单的自实现布隆过滤器的示例代码：

class BloomFilter {

    private $bitArray;

    private $hashFunctions;



    public function __construct($size, $numHashFunctions) {

        $this->bitArray = array_fill(0, $size, false);

        $this->hashFunctions = $numHashFunctions;

    }



    private function hash($value) {

        $hashes = [];

        $hash1 = crc32($value);

        $hash2 = fnv1a32($value);



        for ($i = 0; $i < $this->hashFunctions; $i++) {

            $hashes[] = ($hash1 + $i * $hash2) % count($this->bitArray);

        }



        return $hashes;

    }



    public function add($value) {

        $hashes = $this->hash($value);



        foreach ($hashes as $hash) {

            $this->bitArray[$hash] = true;

        }

    }



    public function has($value) {

        $hashes = $this->hash($value);



        foreach ($hashes as $hash) {

            if (!$this->bitArray[$hash]) {

                return false;

            }

        }



        return true;

    }

}



// 创建一个布隆过滤器

$filter = new BloomFilter(100, 3);



// 向过滤器添加元素

$filter->add("element1");

$filter->add("element2");

$filter->add("element3");



// 检查元素是否存在于过滤器中

if ($filter->has("element1")) {

    echo "Element 1 may exist.";

} else {

    echo "Element 1 does not exist.";

}

无论是使用扩展库还是自行实现，布隆过滤器在处理大规模数据集合时可以提供高效的元素存在性检查功能，适用于需要快速判断元素是否属于某个集合的场景。

通过淘宝weex，微信，美团kmm，天猫Waft 等不同项目来了解目前各家公司在跨平台方向上有哪些不同的项目，用了什么不同技术实现方式，然后在对比常用的react native ，flutter 和WebAssembly具体在技术上的区别在哪里。

客户端渲染执行逻辑

android

层次的底部是 Linux，它提供基本的系统功能，如进程管理，内存管理，设备管理，如：相机，键盘，显示器等内核处理的事情。体系结构第三个部分叫做Java虚拟机，是一种专门设计和优化的 Android Dalvik 虚拟机。应用程序框架层使用Java类形式的应用程序提供了许多的更高级别的服务。允许应用程序开发人员在其应用程序中使用这些服务。应用在最上层，即所有的 Android 应用程序。一般我们编写的应用程序只被安装在这层。应用的例子如：浏览器，游戏等。

绘制流程

1. 
   

   创建视图

   
   

ui生成就是把代码中产生的view和在xml文件配置的view，经过measure，layout，dewa 形成一个完整的view树，并调用系统方法进行绘制。Measure 用深度优先原则递归得到所有视图（View）的宽、高；Layout 用深度优先原则递归得到所有视图（View）的位置；到这里就得到view的在窗口中的布局。Draw 目前 Android 支持了两种绘制方式：软件绘制（CPU）和硬件加速（GPU），会通过系统方法把要绘制的view 合成到不同的缓冲区上

最初的ui配置

构建成内存中的view tree

2.视图布局

3.图层合成

SurfaceFlinger 把缓存 区数据渲染到屏幕，由于是两个不同的进程，所以使用 Android 的匿名共享内存 SharedClient 缓存需要显示的数据来达到目的。 SurfaceFlinger 把缓存区数据渲染到屏幕（流程如下图所示），主要是驱动层的事情，这 里不做太多解释。

4. 系统绘制

绘制过程首先是 CPU 准备数据，通过 Driver 层把数据交给 CPU 渲 染，其中 CPU 主要负责 Measure、Layout、Record、Execute 的数据计算工作，GPU 负责 Rasterization（栅格化）、渲染。由于图形 API 不允许 CPU 直接与 GPU 通信，而是通过中间 的一个图形驱动层（Graphics Driver）来连接这两部分。图形驱动维护了一个队列，CPU 把 display list 添加到队列中，GPU 从这个队列取出数据进行绘制，最终才在显示屏上显示出来。

ios：

架构

1. Core OS layer

• 核心操作系统层包括内存管理、文件系统、电源管理以及一些其他的操作系统任务，直接和硬件设备进行交互

2. Core Services layer

• 核心服务层，我们可以通过它来访问iOS的一些服务。包含: 定位，网络，数据 sql

3. Media layer

• 顾名思义，媒体层可以在应用程序中使用各种媒体文件，进行音频与视频的录制，图形的绘制，以及制作基础的动画效果。

4. Cocoa Touch layer

• 本质上来说它负责用户在iOS设备上的触摸交互操作


• 包括以下这些组件： Multi-Touch Events Core Motion Camera View Hierarchy Localization Alerts Web Views Image Picker Multi-Touch Controls.

ios 的视图树

ios的 绘制流程：

显示逻辑

• CoreAnimation提交会话，包括自己和子树（view hierarchy）的layout状态等；


• RenderServer解析提交的子树状态，生成绘制指令；


• GPU执行绘制指令；


• 显示渲染后的数据；

提交流程

1、布局（Layout）

调用layoutSubviews方法； 调用addSubview:方法；

2、显示（Display）

通过drawRect绘制视图； 绘制string（字符串）；

每个UIView都有CALayer，同时图层有一个像素存储空间，存放视图；调用-setNeedsDisplay的时候，仅会设置图层为dirty。 当一个视图第一次或者某部分需要更新的时候iOS系统总是会去请求drawRect:方法。

以下是触发视图更新的一些操作：

• 移动或删除视图


• 通过将视图的hidden属性设置为NO


• 滚动消失的视图再次需要出现在屏幕上


• 视图显式调用setNeedsDisplay或setNeedsDisplayInRect:方法

视图系统都会自动触发重新绘制。对于自定义视图，就必须重写drawRect:方法去执行所有绘制。视图第一次展示的时候，iOS系统会传递正方形区域来表示这个视图绘制的区域。

在调用drawRect:方法之后，视图就会把自己标记为已更新，然后等待下一次视图更新被触发。

3、准备提交（Prepare）

解码图片； 图片格式转换；

4、提交（Commit）

打包layers并发送到渲染server；

递归提交子树的layers；

web ：

web内容准备阶段

web 通常需要将所需要的html，css，js都下载下来，并进行解析执行后才进行渲染，然后是绘制过程，先来看下前期工作

一个渲染流程会划分很多子阶段，整个处理过程叫渲染流水线，流水线可分为如下几个子阶段：构建DOM树、样式计算、布局阶段、分层、绘制、分块、光栅化和合成。每个阶段都经过输入内容 -->处理过程-->输出内容三个部分。

1. 渲染进程将HTML内容转换为能够读懂的DOM树结构

2. 渲染引擎将CSS样式表转化为浏览器可以理解的styleSheets（生存CSSDOM树），计算出DOM节点的样式

styleSheets格式

3. 创建布局树（LayoutTree），并计算元素的布局信息。

我们有DOM树和DOM树中元素的样式，那么接下来就需要计算出DOM树中可见元素的几何位置，我们把这个计算过程叫做布局。根据元素的可见信息构建出布局树。

4. 对布局树进行分层，并生成分层树(LayerTree)。

5. 为每个图层生成绘制列表，并将其提交到合成线程。

6. 合成线程将图层分成图块，并在光栅化线程池中将图块转换成位图。

合成线程会按照视口附近的图块来优先生成位图，实际生成位图的操作是由栅格化来执行的。所谓栅格化，是指将图块转换为位图。

7. 合成线程发送绘制图块命令DrawQuad给浏览器进程。浏览器进程根据DrawQuad消息生成页面，并显示到显示器上

web 在android 中的绘制

WebView实际上是一个ViewGroup，并将后端的具体实现抽象为WebViewProvider，而WebViewChromium正是一个提供基于Chromium的具体实现类。

再回到WebView的情况。当WebView部件发生内容更新时，例如页面加载完毕，CSS动画，或者是滚动、缩放操作导致页面内容更新，同样会在WebView触发invalidate方法，随后在视图系统的统筹安排下，WebView.onDraw方法会被调用，最后实际上调用了AwContents.onDraw方法，它会请求对应的native端对象执行OnDraw方法，将页面的内容更新绘制到WebView对应的Canvas上去。

draw()先得到一块Buffer,这块Buffer是由SurfaceFlinger负责管理的。

然后调用view的draw(canvas)当view draw完后，调用surface.java的unlockAndPostCanvas().

将包含有当前view内容的Buffer传给SurfaceFlinger,SurfaceFlinger将所有的Buffer混合后传给FrameBuffer.至此和native原有的view 渲染就是一样的了。

成熟的框架的底层原理：

react ：

RN 的 Android Bridge 和 IOS Bridge 是两端通信的桥梁, 是由一个转译的桥梁实现的不同语言的通信, 得以实现单靠 JS 就调用移动端原生 APi

架构

• RN 的核心驱动力就来自 JS Engine, 我们所有的 JS 代码都会通过 JS Engine 来编译执行, 包括 React 的 JSX 也离不开 JS Engine, JavaScript Core 是其中一种 JS 引擎, 还有 Google 的 V8 引擎, Mozilla 的 SpiderMonkey 引擎。


• RN 是用类 XML 语言来表示结构, 用 StyleSheet 来规划样式, 但是 UI 控件调用的是 RN 里自己的两端实现控件(android 和 IOS)

• JavaScript 在 RN 的作用就是给原生组件发送指令来完成 UI 渲染, 所以 JavaScript Core 是 RN 中的核心部分

• RN 是不用 JS 引擎的 UI 渲染控件的, 但是会用到 JS 引擎的 DOM 操作管理能力来管理所有 UI 节点, 每次在写完 UI 组件代码后会交给 yoga 去做布局排版, 然后调用原生组件绘制


• bridge 负责js 和native的通讯，以android为例：Java层与Js层的bridge分别存有相同一份模块配置表，Java与Js互相通信时，通过bridge里的配置表将所调用模块方法转为{moduleID,methodID,args}的形式传递给处理层，处理层通过bridge的模块配置表找到对应的方法执行，如果有callback，则回传给调用层

通讯机制

Java -> Js： Java通过注册表调用到CatalystInstance实例，通过jni，调用到 javascriptCore，传递给调用BatchedBridge.js，根据参数｛moduleID,methodID｝require相应Js模块执行。

Js -> Java： JS不主动传递数据调用Java。在需要调用调Java模块方法时，会把参数｛moduleID,methodID｝等数据存在MessageQueue中，等待Java的事件触发，再把MessageQueue中的｛moduleID,methodID｝返回给Java，再根据模块注册表找到相应模块处理。

事件循环

JS 开发者只需要开发各个组件对象，监听组件事件， 然后利用framework接口调用render方法渲染组件。

而实际上，JS 也是单线程事件循环，不管是 API调用， virtural DOM同步， 还是系统事件监听， 都是异步事件，采用Observer（观察者）模式监听JAVA层事件， JAVA层会把JS 关心的事件通过bridge直接使用javascriptCore的接口执行固定的脚本， 比如"requrire (test_module).test_methode(test_args)"。此时，UI main thread相当于work thread, 把系统事件或者用户事件往JS层抛，同时，JS 层也不断调用模块API或者UI组件 ， 驱动JAVA层完成实际的View渲染。JS开发者只需要监听JS层framework定义的事件即可

react 的渲染流程

首先回顾一下当前Bridge的运行过程。当我们写了类似下面的React源码。

<View style={{ backgroundColor: 'pink', width: 200, height: 200}}/>

JS thread会先对其序列化,形成下面一条消息

UIManager.createView([343,"RCTView",31,{"backgroundColor":-16181,"width":200,"height":200}])

通过Bridge发到ShadowThread。Shadow Tread接收到这条信息后，先反序列化，形成Shadow tree，然后传给Yoga，形成原生布局信息。接着又通过Bridge传给UI thread。UI thread 拿到消息后，同样先反序列化，然后根据所给布局信息，进行绘制。

从上面过程可以看到三个线程的交互都是要通过Bridge，因此瓶颈也就在此。

首次渲染流程

1. Native 打开 RN 页面


2. JS 线程运行，Virtual DOM Tree 被创建


3. JS 线程异步通知 Shadow Thread 有节点变更


4. Shadow Thread 创建 Shadow Tree


5. Shadow Thread 计算布局，异步通知 Main Thread 创建 Views


6. Main Thread 处理 View 的创建，展示给用户

react native 新架构

• JSI：JSI是Javascript Interface的缩写，一个用C++写成的轻量级框架，它作用就是通过JSI，JS对象可以直接获得C++对象(Host Objects)引用，并调用对应方法。

另外JSI与React无关，可以用在任何JS 引擎（V8,Hermes)。有了JSI，JS和Native就可以直接通信了,调用过程如下：JS->JSI->C++->ObjectC/Java

• Fabric 是 UI Manager 的新名称, 将负责 Native UI 渲染, 和当前 Bridge 不同的是, 可以通过 JSI 导出自己的 Native 函数, 在 JS 层可以直接使用这些函数引用, 反过来 Native 可以直接调用 JS 层, 从而实现同步调用, 这带来更好的数据传输和性能提升

对比

flutter：

生产环境中 Dart 通过 AOT 编译成对应平台的指令，同时 Flutter 基于跨平台的 Skia 图形库自建了渲染引擎，最大程度地保证了跨平台渲染的一致性

• embedder： 可以称为嵌入器，这是和底层的操作系统进行交互的部分。因为flutter最终要将程序打包到对应的平台中，对于Android平台使用的是Java和C++，对于iOS和macOS平台，使用的是Objective-C/Objective-C++。

• engine：Flutter engine基本上使用C++写的。engine的存在是为了支持Dart Framework的运行。它提供了Flutter的核心API，包括作图、文件操作、网络IO、dar运行时环境等核心功能。Flutter Engine线程的创建和管理是由embedder负责的。

• Flutter framework： 这一层是用户编程的接口，我们的应用程序需要和Flutter framework进行交互，最终构建出一个应用程序。

Flutter framework主要是使用dart语言来编写的。framework从下到上，我们有最基础的foundational包，和构建在其上的 animation, painting和 gestures 。

再上面就是rendering层，rendering为我们提供了动态构建可渲染对象树的方法,通过这些方法，我们可以对布局进行处理。接着是widgets layer,它是rendering层中对象的组合，表示一个小挂件。

Widgets 理解

Widgets是Flutter中用户界面的基础。你在flutter界面中能够观察到的用户界面，都是Widgets。大的Widgets又是由一个个的小的Widgets组成，这样就构成了Widgets的层次依赖结构,在这种层次结构中，子Widgets可以共享父Widgets的上下文环境。在Flutter中一切皆可为Widget。

举例，这个Containerks 控件里的child，color，Text 都是Widget。

  color: Colors.blue,

  child: Row(

    children: [

      Image.network('http://www.flydean.com/1.png'),

      const Text('A'),

    ],

  ),

);

Widgets表示的是不可变的用户UI界面结构。虽然结构是不能够变化的，但是Widgets里面的状态是可以动态变化的。根据Widgets中是否包含状态，Widgets可以分为stateful和stateless widget,对应的类是StatefulWidget和StatelessWidget。

渲染和绘制

渲染就是将上面我们提到的widgets转换成用户肉眼可以感知的像素的过程。Flutter代码会直接被编译成使用 Skia 进行渲染的原生代码,从而提升渲染效率。

代码首先会形成widgets树如下，这些widget在build的过程中，会被转换为 element tree，其中ComponentElement是其他Element的容器，而RenderObjectElement是真正参与layout和渲染的element。。一个element和一个widget对应。然后根据elementrtree 中需要渲染的元素形成RenderTree ，flutter仅会重新渲染需要被重新绘制的element，每次widget变化时element会比较前后两个widget，只有当某一个位置的Widget和新Widget不一致，才会重新创建Element和widget。 最后还会一个layer tree，表示绘制的图层。

四棵树有各自的功能

Flutter绘制流程

• Animate，触发动画更新下一帧的值


• Build，触发构建或刷新 Widget Tree、Element Tree、RenderObject Tree


• Layout，触发布局操作，确定布局大小和位置信息


• CompositeBits，更新需要合成的 Layer 层标记


• Paint，触发 RenderObject Tree 的绘制操作，构建 Layer Tree


• Composite，触发 Layer Tree 发送到 Engine，生成 Engine LayerTree

在 UIThread 构建出四棵树，并在 Engine 生成 Scene，最后提交给 RasterThread，对 LayerTree 做光栅化合成上屏。

Flutter 渲染流程

• 
  

  UIThread

  
  

  UIThread 是 Platform 创建的子线程，DartVM Root Isolate 所有的 dart 代码都运行在该线程。阻塞 UIThread 会直接导致 Flutter 应用卡顿掉帧。

  
  


• 
  

  RasterThread

  
  

  RasterThread 原本叫做 GPUThread，也是 Platform 创建的子线程，但其实它是运行在 CPU 用于处理数据提交给 GPU，所以 Flutter 团队将其名字改为 Raster，表明它的作用是光栅化。

  
  

  C++ Engine 中的光栅化和合成过程运行在该线程。

  
  


• 
  

  C++ Engine 触发 Platform 注册 VSync 垂直信号回调，通过 Platform -> C++ Engine -> Dart Framework 触发整个绘制流程

  
  


• 
  

  Dart Framework 构建出四棵树，Widget Tree、Element Tree、RenderObject Tree、Layer Tree，布局、记录绘制区域及绘制指令信息生成 flutter::LayerTree，并保存在 Scene 对象用以光栅化，这个过程运行在 UIThread

  
  


• 
  

  通过 Flutter 自建引擎 Skia 进行光栅化和合成操作， 将 flutter::LayerTree 转换为 GPU 指令，并发送给 GPU 完成光栅化合成上屏显示操作，这个过程执行在 RasterThread

  
  

整个调度过程是生产者消费者模型，UIThread 负责生产 flutter::Layer Tree，RasterThread 负责消费 flutter::Layer Tree。

flutter 线程模型

Mobile平台上面每一个Engine实例启动的时候会为UI，GPU，IO Runner各自创建一个新的线程。所有Engine实例共享同一个Platform Runner和线程。

• 
  

  Platform Task Runner

  
  

  Flutter Engine的主Task Runner，可以理解为是主线程，一个Flutter应用启动的时候会创建一个Engine实例，Engine创建的时候会创建一个线程供Platform Runner使用。改线程不仅仅处理与Engine交互，它还处理来自平台的消息。

  
  


• 
  

  UI Task Runner Thread（Dart Runner）

  
  

  UI Task Runner被Flutter Engine用于执行Dart root isolate代码，Root isolate运行应用的main code。负责触发构建或刷新 Widget Tree、Element Tree、RenderObject Tree，生成最终的Layer Tree。

  
  

  Root Isolate还是处理来自Native Plugins的消息响应，Timers，Microtasks和异步IO（isolate是有自己的内存和单线程控制的运行实体，isolate之间的内存在逻辑上是隔离的）。

  
  


• 
  

  GPU Task Runner

  
  

  GPU Task Runner中的模块负责将Layer Tree提供的信息转化为实际的GPU指令，执行设备GPU相关的skia调用，转换相应平台的绘制方式，比如OpenGL, vulkan, metal等。GPU Task Runner同时也负责配置管理每一帧绘制所需要的GPU资源

  
  


• 
  

  IO Task Runne

  
  

IO Runner的主要功能是从图片存储（比如磁盘）中读取压缩的图片格式，将图片数据进行处理为GPU Runner的渲染做好准备

Dart 是单线程的，但是采用了Event Loop 机制，也就是不断循环等待消息到来并处理。在 Dart 中，实际上有两个队列，一个事件队列（Event Queue），另一个则是微任务队列（Microtask Queue）。在每一次事件循环中，Dart 总是先去第一个微任务队列中查询是否有可执行的任务，如果没有，才会处理后续的事件队列的流程。

isolate机制尽管 Dart 是基于单线程模型的，但为了进一步利用多核 CPU，将 CPU 密集型运算进行隔离，Dart 也提供了多线程机制，即 Isolate。每个 Isolate 都有自己的 Event Loop 与 Queue，Isolate 之间不共享任何资源，只能依靠消息机制通信，因此也就没有资源抢占问题。Isolate 通过发送管道（SendPort）实现消息通信机制。我们可以在启动并发 Isolate 时将主 Isolate 的发送管道作为参数传给它，这样并发 Isolate 就可以在任务执行完毕后利用这个发送管道给我们发消息。

如果需要在启动一个 Isolate 执行某项任务，Isolate 执行完毕后，发送消息告知我们。如果 Isolate 执行任务时，同时需要依赖主 Isolate 给它发送参数，执行完毕后再发送执行结果给主 Isolate这样的双向通信，让并发 Isolate 也回传一个发送管道即可。

weex：

架构：

1. 将weex源码生成JS Bundle,由template、style 和 script等标签组织好的内容，通过转换器转换成JS Bundle


2. 服务端部署JS Bundle ,将JS Bundle部署在服务器，当接收到终端（Web端、iOS端或Android端）的JS Bundle请求，将JS Bundle下发给终端


3. WEEX SDK初始化,初始化 JS 引擎，准备好 JS 执行环境


4. 构建渲染指令树,Weex 里都使用 DOM API 把 Virtual DOM 转换成真实的Element 树，而是使用 JS Framework 里定义的一套 Weex DOM API 将操作转化成渲染指令发给客户端，形成客户端的真实控件


5. 页面的 js 代码是运行在 js 线程上的，然而原生组件的绘制、事件的捕获都发生在 UI 线程。在这两个线程之间的通信用的是 callNative 和 callJS 这两个底层接口。callNative 是由客户端向 JS 执行环境中注入的接口，提供给 JS Framework 调用。callJS 是由 JS Framework 实现的，并且也注入到了执行环境中，提供给客户端调用。

渲染过程

Weex 里页面的渲染过程和浏览器的渲染过程类似，整体可以分为【创建前端组件】-> 【构建 Virtual DOM】->【生成“真实” DOM】->【发送渲染指令】->【绘制原生 UI】这五个步骤。前两个步骤发生在前端框架中，第三和第四个步骤在 JS Framework 中处理，最后一步是由原生渲染引擎实现的。 页面渲染的大致流程如下

各家项目的实现方式：

淘宝新⼀代⾃绘渲染引擎 的架构与实践

Weex 技术发展历程

Weex 2.0 简版架构

最上层的前端生态还是没变的，应该还是以vue的响应式编程为主。

2.0多了js和c++的直接调用，减少js引擎和布局引擎的通讯开销。

Weex 2.0 重写了渲染层的实现，不再依赖系统 UI，改成依赖统一的图形库 Skia 自绘渲染，和 Flutter 原理很像，我们也直接复用了 Flutter Engine 的部分代码。底层把 Weex 对接过的各种原生能力、三方扩展模块都原样接入。对于上层链路，理论上讲业务 JS 代码、Vue/Rax、JS Framework 都是不需要修改的。在 JS 引擎层面也做了一些优化，安卓上把 JavaScriptCore 换成了 QuickJS，用 bytecode 加速二次打开性能，并且结合 Weex js bundle 的特点做针对性的优化。

字节码编译原理

渲染原理

渲染引擎通用的渲染管线可以简化为【执行脚本】-->【构建节点】-->【布局/绘制】--> 【合成/光栅化】--【上屏】这几个步骤。Weex 里的节点构建逻辑主要在 JS 线程里执行，提交一颗静态节点树到 UI 线程，UI 线程计算布局和绘制属性，生成 Layer Stack 提交到 GPU 线程。

天猫：WAFT：基于WebAssembly和Skia 的AIoT应用开发框架

整体方案

为什么选择WebAssemy？

支持 AOT 模式，拔高了性能上限；活跃的开源社区，降低项目推进的风险；支持多语言，拓宽开发者群体。

WebAssembly（又名wasm）是一种高效的，低级别的编程语言。 它让我们能够使用JavaScript以外的语言（例如C，C ++，Rust或其他）编写程序，然后将其编译成WebAssembly，进而生成一个加载和执行速度非常快的Web应用程序

WebAssembly是基于堆栈的虚拟机的二进制指令格式，它被设计为编程语言的可移植编译目标。目前很多语言都已经将 WebAssembly 作为它的编译目标了。

waft 开发方式

可以看到是采用类前端的开发方式，限定一部分css能力。最后编译为WebAssembly，打包成wasm bundle。 在进行aot 编译城不同架构下的机器码。

运行流程

可以看到bundle 加载过程中，会执行UI区域的不同的生命周期函数。然后在渲染过程则是从virtual dom tree 转化到widget tree，然后直接通过skia 渲染库直接进行渲染。

Waft 第二阶段成果-跨平台

美团KMM在餐饮SaaS中的探索与实践

KMP：Kotlin Multiplatform projects 使用一份kotlin 代码在不同平台上运行

KMM：Kotlin MultiplatformMobile 一个用于跨平台移动应用程序的 SDK。使用 KMM，可以构建多平台移动应用程序并在 Android 和 iOS 应用程序之间共享核心层和业务逻辑等方面。开发人员可以使用单一代码库并通过共享数据层和业务逻辑来实现功能。其实就是把一份逻辑代码编译为多个平台的产物编译中间产物，在不同平台的边缘后端下转为不同的变异后端产物，在不同平台下运行。

IR 全称是 intermediate representation，表示编译过程中的中间信息，由编译器前端对源码分析后得到，随后会输入到后端进一步编译为机器码

IR 可以有一系列的表现方式，由高层表示逐渐下降(lowering)到低层

我们所讨论的 Kotlin IR 是抽象语法树结构（AST），是比较高层的 IR 表示类型。

有了完备的 IR，就可以利用不同的 后端，编出不同的目标代码，比如 JVM 的字节码，或者运行在 iOS 的机器码，这样就达到了跨端的目的

对比

总结

当前存在4种多端方案：

1. Web 容器方案


2. 泛 Web 容器方案


3. 自绘引擎方案


4. 开放式跨端框架

引用文章：

zhuanlan.zhihu.com/p/20259704​​

zhuanlan.zhihu.com/p/281238593​​

zhuanlan.zhihu.com/p/388681402​​

juejin.cn/post/708412…​​

guoshuyu.cn/home/wx/Flu…​​

oldbird.run/flutter/u11…​​

w4lle.com/2020/11/09/…​​

blog.51cto.com/jdsjlzx/568…​​

http://www.devio.org/2021/01/10/…​​

gityuan.com/flutter/​​

gityuan.com/2019/06/15/…​​

zhuanlan.zhihu.com/p/78758247​​

http://www.finclip.com/news/f/5

Redis 的数据 全部存储 在 内存 中，如果 突然宕机，数据就会全部丢失，因此必须有一套机制来保证 Redis 的数据不会因为故障而丢失，这种机制就是 Redis 的 持久化机制，它会将内存中的数据库状态 保存到磁盘 中。

Redis 中的两种持久化方式： RDB（Redis DataBase）和 AOF（Append Of File）

1. RDB（Redis DataBase）

在指定的 时间间隔内 将内存中的数据集 快照 写入磁盘，也就是行话讲的快照（Snapshot），它恢复时是将快照文件直接读到内存里

1.1 原理

不使用Fork存在的问题

• 
  

  Redis 是一个 单线程 的程序，这意味着，我们不仅仅要响应用户的请求，还需要进行内存快照。而后者要求 Redis 必须进行 IO 操作，这会严重拖累服务器的性能。

  
  


• 
  

  在 持久化的同时，内存数据结构 还可能在 变化，比如一个大型的 hash 字典正在持久化，结果一个请求过来把它删除了，可是这才刚持久化结束。

  
  

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到 一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。 整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能 如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是 最后一次持久化后的数据可能丢失。

1.2 fork 函数

根据操作系统多进程 COW(Copy On Write) 机制，Redis 在持久化时会调用 glibc 的函数 fork 产生一个子进程，简单理解也就是基于当前进程 复制 了一个进程，主进程和子进程会共享内存里面的代码块和数据段。

• Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程


• 在Linux程序中，fork()会产生一个和父进程完全相同的子进程，但子进程在此后多会exec系统调用，出于效率考虑，Linux中引入了“写时复制技术”


• 一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

1.3 RDB流程图

1.4 RDB相关配置

1.4.1 配置文件

• RDB文件默认在redis主目录下的 dump.rdb中

• 快照默认的保持策略

1. 先前的快照是在3600秒（1小时）前创建的，并且现在已经至少有 1 次新写入，则将创建一个新的快照；


2. 先前的快照是在300秒（5分钟）前创建的，并且现在已经至少有 100 次新写入，则将创建一个新的快照；


3. 先前的快照是在60秒（1分钟）前创建的，并且现在已经至少有 10000 次新写入，则将创建一个新的快照；

1.4.2 相关指令

save ：save时只管保存，其它不管，全部阻塞。手动保存。不建议。

bgsave： Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。

lastsave：获取最后一次成功执行快照的时间

1.5 RDB如何备份

1. config get dir  查询rdb文件的目录


2. 关闭Redis


3. 将备份文件 dump.rdb 移动到 redis 安装目录并启动 redis 服务即可，备份数据会直接加载。

2. AOF（Append Of File）

RDB快照不是很持久。如果运行 Redis 的计算机停止运行，电源线出现故障或者您 kill -9 的实例意外发生，则写入 Redis 的最新数据将丢失。

2.1 原理

AOF（Append Of File） 是以 日志 的形式来记录每个写操作（增量保存），将Redis执行过的所有写指令记录下来( 读操作不记录 ) ， 只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作

2.2 AOF流程图

1. 客户端的请求写命令会被append追加到AOF缓冲区内；


2. AOF缓冲区根据AOF持久化策略[always,everysec,no]将操作sync同步到磁盘的AOF文件中；


3. AOF文件大小超过重写策略或手动重写时，会对AOF文件rewrite重写，压缩AOF文件容量；


4. Redis服务重启时，会重新load加载AOF文件中的写操作达到数据恢复的目的；

2.3 AOF相关配置

2.3.1 AOF启动配置

配置文件默认关闭AOF，将配置文件设置为 appendonly yes 启动AOF。

AOF和RDB同时开启，系统默认取AOF的数据（数据不会存在丢失）

2.3.2 AOF 同步fsync频率设置

• appendfsync always始终同步，每次Redis的写入都会立刻记入日志；性能较差但数据完整性比较好


• appendfsync everysec每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。


• appendfsync noredis不主动进行同步，把同步时机交给操作系统。

借助 glibc 提供的 fsync(int fd) 函数来讲指定的文件内容 强制从内核缓存刷到磁盘。但  "强制开车"  仍然是一个很消耗资源的一个过程，需要  "节制" ！通常来说，生产环境的服务器，Redis 每隔 1s 左右执行一次 fsync 操作就可以了。

Redis 同样也提供了另外两种策略，一个是 永不 fsync，来让操作系统来决定合适同步磁盘，很不安全，另一个是 来一个指令就 fsync 一次，非常慢。但是在生产环境基本不会使用，了解一下即可。

2.3.3 查看appendonly.aof文件

最后一条del non_existing_key没有追加到appendonly.aof文件中，因为它没有对数据实际造成修改

2.4 AOF如何备份

修改默认的appendonly no，改为yes

2.4.1 正常恢复

1. config get dir  查询rdb文件的目录


2. 关闭Redis


3. 将备份文件 appendonly.aof 移动到 redis 安装目录并启动 redis 服务即可，备份数据会直接加载。

2.4.2 异常恢复

1. 如遇到AOF文件损坏，通过/usr/local/bin/redis-check-aof--fix appendonly.aof进行恢复备份被写坏的AOF文件。


2. 恢复：重启redis，备份数据会直接加载。

2.5 Rewrite重写

Redis 在长期运行的过程中，AOF 的日志会越变越长。如果实例宕机重启，重放整个 AOF 日志会非常耗时，导致长时间 Redis 无法对外提供服务。所以需要对 AOF 日志 "瘦身" 。
Redis 提供了 bgrewriteaof 指令用于对 AOF 日志进行瘦身。其 原理 就是 开辟 (fork) 一个子进程 对内存进行 遍历 转换成一系列 Redis 的操作指令，序列化到一个新的 AOF 日志文件 中。序列化完毕后再将操作期间发生的 增量 AOF 日志 追加到这个新的 AOF 日志文件中，追加完毕后就立即替代旧的 AOF 日志文件了，瘦身工作就完成了。

2.5.1 配置文件

• no-appendfsync-on-rewrite=yes：不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）


• no-appendfsync-on-rewrite=no：还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

• auto-aof-rewrite-percentage：设置重写的基准值，文件达到100%时开始重写（文件是原来重写后文件的2倍时触发）


• auto-aof-rewrite-min-size：设置重写的基准值，最小文件64MB。达到这个值开始重写。

例如：文件达到70MB开始重写，降到50MB，下次什么时候开始重写？100MB

系统载入时或者上次重写完毕时，Redis会记录此时AOF大小，设为base_size,

如果Redis的AOF当前大小>= base_size +base_size*100% (默认)且当前大小>=64mb(默认)的情况下，Redis会对AOF进行重写。

2.5.2 Rewrit流程图

1. bgrewriteaof触发重写，判断是否当前有bgsave或bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行。


2. 主进程fork出子进程执行重写操作，保证主进程不会阻塞。


3. 子进程遍历redis内存中数据到临时文件，客户端的写请求同时写入aof_buf缓冲区和aof_rewrite_buf重写缓冲区保证原AOF文件完整以及新AOF文件生成期间的新的数据修改动作不会丢失。


4. 子进程写完新的AOF文件后，向主进程发信号，父进程更新统计信息。2).主进程把aof_rewrite_buf中的数据写入到新的AOF文件。


5. 使用新的AOF文件覆盖旧的AOF文件，完成AOF重写。

3. 总结

3.1 Redis 4.0 混合持久化

重启 Redis 时，我们很少使用 rdb 来恢复内存状态，因为会丢失大量数据。我们通常使用 AOF 日志重放，但是重放 AOF 日志性能相对 rdb 来说要慢很多，这样在 Redis 实例很大的情况下，启动需要花费很长的时间。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小，于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

3.2 官方建议

• 官方推荐两个都启用。


• 如果对数据不敏感，可以选单独用RDB。


• 不建议单独用 AOF，因为可能会出现Bug。


• 如果只是做纯内存缓存，可以都
  
  作者：芒猿君
  来源：juejin.cn/post/7249382407245037623
  不用。

背景

我们编写的Web项目部署之后，经常会因为需要进行配置变更或功能迭代而重启服务，单纯的kill -9 pid的方式会强制关闭进程，这样就会导致服务端当前正在处理的请求失败，那有没有更优雅的方式来实现关机或重启呢？

优雅停机

在项目正常运行的过程中，如果直接不加限制的重启可能会发生一下问题

1. 项目重启（关闭）时，调用方可能会请求到已经停掉的项目，导致拒绝连接错误（503），调用方服务会缓存一些服务列表导致，服务列表依然还有已经关闭的项目实例信息


2. 项目本身存在一部分任务需要处理，强行关闭导致这部分数据丢失，比如内存队列、线程队列、MQ 关闭导致重复消费

为了解决上面出现的问题，提供以下解决方案：

1. 关于问题 1 采用将需要重启的项目实例，提前 40s 从 nacos 上剔除，然后再重启对应的项目，保证有 40s 的时间可以用来服务发现刷新实例信息，防止调用方将请求发送到该项目


2. 使用 Spring Boot 提供的优雅停机选项，再次预留一部分时间


3. 使用 shutdonwhook 完成自定的关闭操作

一、主动将服务剔除

该方案主要考虑因为服务下线的瞬间，如果 Nacos 服务剔除不及时，导致仍有部分请求转发到该服务的情况

在项目增加一个接口，同时在准备关停项目前执行 stop 方法，先主动剔除这个服务，shell 改动如下：

run.sh

function stop()  

{  

    echo "Stop service please waiting...."  

    echo "deregister."  

    curl -X POST "127.0.0.1:${SERVER_PORT}/discovery/deregister"  

    echo ""  

    echo "deregister [${PROJECT}] then sleep 40 seconds."  

    # 这里 sleep 40 秒，因为 Nacos 默认的拉取新实例的时间为 30s, 如果调用方不修改的化，这里应该最短为 30s

    # 考虑到已经接收的请求还需要一定的时间进行处理，这里预留 10s, 如果 10s 还没处理完预留的请求，调用方肯定也超时了  

    # 所以这里是 30 + 10 = 40sleep 40  

    kill -s SIGTERM ${PID} 

    if [ $? -eq 0 ];then  

        echo "Stop service done."

    else  

        echo "Stop service  failed!"  

    fi

}

在项目中增加 /discovery/deregister 接口

Spring Boot MVC 版本

import lombok.extern.slf4j.Slf4j;  

import org.springframework.beans.factory.annotation.Autowired;  

import org.springframework.cloud.client.serviceregistry.Registration;  

import org.springframework.cloud.client.serviceregistry.ServiceRegistry;  

import org.springframework.context.annotation.Lazy;  

import org.springframework.web.bind.annotation.PostMapping;  

import org.springframework.web.bind.annotation.RequestMapping;  

import org.springframework.web.bind.annotation.RestController;  

  

@SuppressWarnings("SpringJavaAutowiredFieldsWarningInspection")  

@RestController  

@RequestMapping("discovery")  

@Slf4j  

public class DeregisterInstanceController {  

  

	@Autowired

	@Lazy  

	private ServiceRegistry serviceRegistry;  

  

	@Autowired  

	@Lazy  

	private Registration registration;  

  

	

	@PostMapping("deregister")  

	public ResultVO<String> deregister() {  

		log.info("deregister serviceName:{}, ip:{}, port:{}",  

		registration.getServiceId(),  

		registration.getHost(),  

		registration.getPort());  

		try {  

			serviceRegistry.deregister(registration);  

		} catch (Exception e) {  

			log.error("deregister from nacos error", e);  

			return ResultVO.failure(e.getMessage());  

		}  

            return ResultVO.success();  

	}

}

Spring Cloud Gateway

通过使用 GatewayFilter 方式来处理

package com.br.zeus.gateway.filter;  

  

import static org.springframework.cloud.gateway.support.ServerWebExchangeUtils.isAlreadyRouted;  

  

import com.alibaba.fastjson.JSON;  

import com.br.zeus.gateway.entity.RulesResult;  

import lombok.extern.slf4j.Slf4j;  

import org.springframework.beans.factory.annotation.Autowired;  

import org.springframework.cloud.client.serviceregistry.Registration;  

import org.springframework.cloud.client.serviceregistry.ServiceRegistry;  

import org.springframework.cloud.gateway.filter.GatewayFilter;  

import org.springframework.cloud.gateway.filter.GatewayFilterChain;  

import org.springframework.context.annotation.Lazy;  

import org.springframework.core.Ordered;  

import org.springframework.core.io.buffer.DataBuffer;  

import org.springframework.http.HttpStatus;  

import org.springframework.http.MediaType;  

import org.springframework.http.server.reactive.ServerHttpResponse;  

import org.springframework.stereotype.Component;  

import org.springframework.web.server.ServerWebExchange;  

import reactor.core.publisher.Mono;  

  

@SuppressWarnings("SpringJavaAutowiredFieldsWarningInspection")  

@Component  

@Slf4j  

public class DeregisterInstanceGatewayFilter implements GatewayFilter, Ordered {  

  

	@Autowired  

	@Lazy  

	private ServiceRegistry serviceRegistry;  

  

	@Autowired  

	@Lazy  

	private Registration registration;  

  

	public DeregisterInstanceGatewayFilter() {  

		log.info("DeregisterInstanceGatewayFilter 启用");  

	}  

  

	@Override  

	public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {  

		if (isAlreadyRouted(exchange)) {  

			return chain.filter(exchange);  

		}  

  

		log.info("deregister serviceName:{}, ip:{}, port:{}",  

		registration.getServiceId(),  

		registration.getHost(),  

		registration.getPort());  

  

		RulesResult result = new RulesResult();  

		try {  

			serviceRegistry.deregister(registration);  

			result.setSuccess(true);  

		} catch (Exception e) {  

			log.error("deregister from nacos error", e);  

			result.setSuccess(false);  

			result.setMessage(e.getMessage());  

		}  

		  

		ServerHttpResponse response = exchange.getResponse();  

		response.getHeaders().setContentType(MediaType.APPLICATION_JSON_UTF8);  

		DataBuffer bodyDataBuffer = response.bufferFactory().wrap(JSON.toJSONBytes(result));  

		response.setStatusCode(HttpStatus.OK);  

		return response.writeWith(Mono.just(bodyDataBuffer));  

	}  

  

	@Override  

	public int getOrder() {  

		return 0;  

	}  

}

在路由配置时，增加接口和过滤器的关系

.route("DeregisterInstance", r -> r.path("/discovery/deregister")  

	.filters(f -> f.filter(deregisterInstanceGatewayFilter))  

	.uri("https://example.com"))

二、Spring Boot 自带的优雅停机方案

要求 Spring Boot 的版本大于等于 2.3

在配置文件中增加如下配置：

application.yaml

server:  

	shutdown: graceful

spring:

  lifecycle:

    timeout-per-shutdown-phase: 10s

当使用 server.shutdown=graceful 启用时，在 web 容器关闭时，web 服务器将不再接收新请求，并将等待活动请求完成的缓冲期。使用 timeout-per-shutdown-phase 配置最长等待时间，超过该时间后关闭

三、使用 ShutdownHook

public class MyShutdownHook {

    public static void main(String[] args) {

        // 创建一个新线程作为ShutdownHook

        Thread shutdownHook = new Thread(() -> {

            System.out.println("ShutdownHook is running...");

            // 执行清理操作或其他必要的任务

	        // 1. 关闭 MQ

	        // 2. 关闭线程池

	        // 3. 保存一些数据

        });



        // 注册ShutdownHook

        Runtime.getRuntime().addShutdownHook(shutdownHook);



        // 其他程序逻辑

        System.out.println("Main program is running...");



        // 模拟程序执行

        try {

            Thread.sleep(5000); // 假设程序运行5秒钟

        } catch (InterruptedException e) {

            e.printStackTrace();

        }



        // 当程序退出时，ShutdownHook将被触发执行

    }

}
作者：双鬼带单
来源：juejin.cn/post/7249286832168566840

35岁是一个让程序员感到焦虑的年龄。这个年纪往往意味着成熟和稳定，但在技术领域，35岁可能意味着过时和被淘汰。在这篇文章中，我将探讨35岁程序员的思考，以及如何应对这种感受，这里我不想贩卖焦虑，只是对现实的一些思考。

当我在20多岁研究生刚刚毕业的时候，恰逢互联网蓬勃发展，到处都是机会，那时候年轻气盛，我充满了能量和热情。我渴望学习新的技术和承担具有挑战性的项目。我花费了无数的时间编码、测试和调试，常常为了追求事业目标而牺牲了个人生活。

慢慢的当我接近30岁的时候，我开始意识到我的优先事项正在转变。我在职业生涯中取得了很多成就，但我也想专注于我的个人生活和关系。我想旅行、和亲人朋友共度时光，并追求曾经被工作忽视的爱好。

现在，35岁的我发现自己处于一个独特的位置。我在自己的领域中获得了丰富的经验，受到同事和同行的尊重。然而，我也感到一种不安和渴望尝试新事物的愿望。这时候我很少在代码上花费时间，而是更多的时间花到了项目管理上，一切似乎很好，但是疫情这几年，行业了很大的影响，公司的运营也变得步履维艰，在安静的会常常想到未来的的规划。

一、焦虑情绪的来源

35岁程序员的焦虑情绪源于其所处的行业环境。技术不断发展，新的编程语言、框架、工具层出不穷，要跟上这些变化需要付出大量的时间和精力。此外，随着年龄的增长，身体和心理健康也会面临各种问题。这些因素加在一起，让35岁程序员感到无从下手，不知道该如何面对未来。

二、面对焦虑情绪的方法

1学习新技能

学习新技能是应对技术革新的必经之路。与其等待公司提供培训或者等待机会，35岁程序员应该主动寻找新技术，并投入时间和精力去学习。通过参加课程、阅读文献，甚至是找到一位 mentor，35岁程序员可以更快地适应新技术，保持竞争力。

2关注行业动态

35岁程序员要时刻关注技术行业的最新动态。阅读技术博客、参加社区活动，以及了解公司的发展方向和战略规划，这些都是成为行业领跑者所必须的。通过增强对行业趋势的了解，35岁程序员可以更好地做出决策，同时也可以通过分享经验获得他人的认可和支持。

3 与年轻人合作

与年轻的程序员合作可以带来许多好处。他们可能拥有更新的知识和技能，并且乐于探索新事物。35岁的程序员应该通过与年轻人合作，学习他们的思考方式和方法论。这样不仅可以加速学习新技能，还可以提高自己的领导能力。

每周我都会组织公司内部的技术交流活动，并积极号召大家发表文章，通过这些技术分享，我发现每个人擅长的东西不同，交流下来大家的收获都很大。

4重新审视个人价值观

在35岁之后，程序员可能会重新审视自己的职业生涯和个人发展方向。当面临焦虑情绪时，建议去回顾一下自己的愿景和目标。这有助于确定下一步的工作方向和计划。此外，35岁程序员也应该考虑个人的非技术技能，例如领导力、沟通能力和团队合作精神，这些技能对长期职业成功至关重要。

5 敞开心扉学会沟通

 程序员给大家的一个刻板印象就是不爱沟通，刻板木讷，大家都是干活的好手，但是一道人际关系处理上就显得有些不够灵活，保持竞争力的一个很关键的点也在于多沟通，多社交，让自己显得更有价值，有一句老话说的好：多一个朋友，多一条路。沟通需要技巧，交朋友更是，这也是我们需要学习的。

三、总结

35岁是程序员生涯中的一个重要节点，同时也是一个充满挑战和机会的时期。如何应对焦虑情绪，保持竞争力并保持个人发展的连续性，这需要程序员深入思考自己的职业规划和发展方向。

通过学习新技能、关注行业动态、与年轻人合作以及审视个人价值观，35岁程序员可以在未来的职业生涯中不断成长和发展。

归根到底，无论如何生活的好与坏都在于我们对待生活的态度，幸福是一种感受，相由心生，无论你处于何种生活状态，

今天又学习了一个装X概念——句柄，看字面意思，感觉跟某种器具有关，但实际上，这个词可不是用来打造家居用品的。

相信不少人跟我一样，第一眼看到这个词，脑海里只有一个大大的问号。不过，没关系，我们可以一起学习，毕竟，装X路上永远没有止境。

1、官方一点儿的定义

在计算机科学中，句柄（Handle）是一种引用或标识对象的方式，它可以用来访问或操作底层系统资源。

不同的操作系统可能会有不同的实现和用途，下面我将以不同的操作系统为例来解释句柄的意义。

1. Windows操作系统

在 Windows 中，句柄是一种整数值，用于标识和访问系统对象或资源，如窗口、文件、设备等。

句柄充当了对象的唯一标识符，通过句柄可以对对象进行操作和管理。

示例代码（C++）：

HWND hWnd = CreateWindow(L"Button", L"Click Me", WS_VISIBLE | WS_CHILD, 10, 10, 100, 30, hWndParent, NULL, hInstance, NULL);

if (hWnd != NULL) {

    // 使用句柄操作窗口对象

    ShowWindow(hWnd, SW_SHOW);

    UpdateWindow(hWnd);

    // ...

}

在上述代码中，通过 CreateWindow 函数创建一个按钮窗口，并将返回的句柄存储在 hWnd 变量中。然后，可以使用 hWnd 句柄来显示窗口、更新窗口等操作。

2. Linux操作系统

在 Linux 中，句柄通常称为文件描述符（File Descriptor），它是一个非负整数，用于标识打开的文件、设备、管道等。

Linux将所有的I/O操作都抽象为文件，并使用文件描述符来引用和操作这些文件。

示例代码（C）：

int fd = open("file.txt", O_RDONLY);

if (fd != -1) {

    // 使用文件描述符读取文件内容

    char buffer[1024];

    ssize_t bytesRead = read(fd, buffer, sizeof(buffer));

    // ...

    close(fd);

}

上述代码中，通过 open 函数打开文件 file.txt，并将返回的文件描述符存储在 fd 变量中。然后，可以使用 fd 文件描述符来进行文件读取等操作。

3. macOS操作系统

在 macOS 中，句柄也称为文件描述符（File Descriptor），类似于 Linux 操作系统的文件描述符。它是一个整数，用于标识和访问打开的文件、设备等。

示例代码（Objective-C）：

int fileDescriptor = open("/path/to/file.txt", O_RDONLY);

if (fileDescriptor != -1) {

    // 使用文件描述符读取文件内容

    char buffer[1024];

    ssize_t bytesRead = read(fileDescriptor, buffer, sizeof(buffer));

    // ...

    close(fileDescriptor);

}

在上述代码中，通过 open 函数打开文件 /path/to/file.txt，并将返回的文件描述符存储在 fileDescriptor 变量中。然后，可以使用 fileDescriptor 文件描述符来进行文件读取等操作。

总结起来，句柄（Handle）是一种在操作系统中用于标识、访问和操作系统资源的方式。

不同的操作系统有不同的实现和命名，如 Windows 中的句柄、Linux 和 macOS 中的文件描述符。句柄提供了一种抽象层，使得程序可以使用标识符来引用和操作底层资源，从而实现对系统资源的管理和控制。

2、通俗易懂的理解

可以把句柄理解为一个中间媒介，通过这个中间媒介可控制、操作某样东西。

举个例子。door handle 是指门把手，通过门把手可以去控制门，但 door handle 并非 door 本身，只是一个中间媒介。

又比如 knife handle 是刀柄，通过刀柄可以使用刀。

跟 door handle 类似，我们可以用 file handle 去操作 file, 但 file handle 并非 file 本身。这个 file handle 就被翻译成文件句柄，同理还有各种资源句柄。

3、为什么要发明句柄？

句柄的引入主要是为了解决以下几个问题：

1. 
   

   资源标识：操作系统中存在各种类型的资源，如窗口、文件、设备等。为了标识和引用这些资源，需要一种统一的方式。句柄提供了一个唯一的标识符，可以用于识别特定类型的资源。

   
   


2. 
   

   封装和抽象：句柄将底层资源的具体实现进行了封装和抽象，提供了一种更高层次的接口供应用程序使用。这样，应用程序不需要了解资源的内部细节和底层实现，只需要通过句柄进行操作。

   
   


3. 
   

   安全性和隔离：句柄可以充当一种权限验证的机制，通过句柄来访问资源可以进行权限检查，从而保证了资源的安全性。此外，句柄还可以实现资源的隔离，不同句柄之间的资源操作互不影响。

   
   


4. 
   

   跨平台和兼容性：不同的操作系统和平台有各自的资源管理方式和实现，句柄提供了一种统一的方式来操作不同平台上的资源。这样，应用程序可以在不同的操作系统上运行，并使用相同的句柄接口来访问资源。

   
   

总之，句柄提供了一种统一、封装、安全和跨平台的解决方案，使得应用程序可以更方便地操作和管理底层系统资源。

好了，看完以上内容你也许会感叹：句柄？这不就是个把手吗！但是，别小瞧这个

用户周期

对于我们各个平台来说（掘金也是），我们用户都会有一个生命周期：引入期--成长期--成熟期--休眠期--流失期。

而一般获客就在引入期，在这个时候我们会通过推广的手段进行拉新；升值期则发生在成长期和成熟期，在两个阶段，我们会通过各种裂变营销（比如红包、券、积分、满减等手段）去实现用户的转化；那到了休眠期和流失期，平台则会通过精准营销去实现用户的留存。

详细的表格可以看下面：

运营手法

讲完了用户周期，我们再来说一下运营手法（让大家做一只明白的羊）。目前比较主流的运营手法包括红包、优惠券、返现、积分、裂变营销、砍价、秒杀......

拼xx新人红包：

饿了X红包：

拼xx砍价

其他我们就不列举了，大家生活中肯定有很多体会。在不同的行业，我们被“安排”的方式是不一样的。我们拿3个行业来举例子：

潜在风险

那从企业的角度出发，在这些环节当中，有可能会出现如下的一些常见风险：客户端风险、账号安全风险、营销活动风险、交易支付风险、爬虫风险。我们一一来过一下这些风险：

1.客户端风险：

2.账户安全风险

3.营销活动风险

4.交易支付风险

5.爬虫风险

黑灰产风险

1.简单介绍

目前我们网络黑灰产的从业人数已经超过1000万（和今年毕业的大学生人数有的一比了），其产业造成的损失每年也已经超过千亿。如今数据泄露已经成为社会问题，也引起了各大企业的重视。并且有个点（可能会被喷），部分的黑灰产的安全攻防人员专业度已经超过我们很多安全技术人员了。毕竟只有千年做贼的，没有千年防贼的。

那在我们的AI技术加持之下，我们后续的黑灰产发展必将和产业链会进一步深度融合，同时目前有一个很显著的特征是：黑灰产正在尝试将自己的攻击行为隐藏在其他用户的行为之。

另外，目前受攻击比较多的行业会包括说电商、出行、政务、直播、广告、游戏、社交等，而分布的场景则是我们前面说的爬虫攻击、薅羊毛、账户风险、交易支付等等。

2.欺诈流程

我们来讲一下黑灰产一般的攻击手段，也就是欺诈的一个流程：

第一步：账号准备。这一步会包括说图里的社工、注册机这些比较常用和典型的，也有其他一些方式。

第二步：情报收集。这一步包括流程的体验以及工具的准备。

第三步：伺机而发。等待活动开始，直接上去薅羊毛

第四步：利益套现。他们会代理或者海鲜市场等等，进行套现。代理的话，游戏行业会用的更多，而海鲜市场，类似于电商的优惠券之类的，会用的比较多。

欺诈工具

目前主流的欺诈工具有如下几种：

1.模拟器：这个主要是针对弱防护的场景

2.设备牧场：现在是应该发展到了第三代全托管牧场。一般可以去做设备识别，针对环境监测和真机检测。

3.接码平台：这个大家应该很熟悉。我们公司做的是安全验证码，而来注册的一部分客户则来找的是接码平台。

4.打码平台：这个其实和接码平台是类似的，不过接码平台针对的是短信验证码，而打码平台针对的是滑动验证码、图片验证码等等。

举个例子：某宝KFC代下单服务泛滥

这块我就不介绍更多了，生怕有人学坏哈哈

防护措施

因为企业目前对这一块都比较重视，所以随之而来的安全产品目前也发展到了一定的阶段。总的来说，目前一般会采取如下的防御体系：

基本是3个平台+3个场景+2个服务

产品一般会组合使用（单个场景针对使用也是可以的），会包括：设备指纹+无感验证+端加固+安全SDK
平台：实施决策平台+智能建模平台+关联网络平台
场景：基本上针对的场景就是我前面说的那些营销场景

方案优势

那通过上面这一套方案，我们可以做到：

事前： 需要在事前事中事后多点进行布控，各环节分别进行防控。

事中： 事中的防控可以将更多的黑名单数据反馈到事前环节的判断。

事前： 事后的分析与建模可以将模型能力赋予事中的风险防控，同时也可以积累大量的黑样本供事前风险防控来使用。

基于标准数据接口进行的模块化组合设计，基于成熟的技术架构和技术优势，可定制、可扩展、可集成、跨平台，在个性化需求的处理方面，有着很好的优势。产品各个模块之间既可相互组合又可自定义配置，灵活的产品配置方式和架构设计思想，可结合不同的业务场景及系统状况进行相应的风险防控方案配置。

结语

在现在AI诈骗频发的时代，其实更受冲击的是金融银行的业务安全，因为我们账号汇款目前用的比较多的是人脸识别，那通过AI换脸，黑灰产完全可以实现相应的技术替换。虽然说这个是用户自己的信息泄露导致的安全问题，但是在问责上，肯定银行也会或多或少受到影响，所以最好是能够有一个合适的风控系统去进行相应的处理。

等端午结束之后吧，有空写一篇关于AI诈骗横行的当下，金融银行要如何应对。<

以上。

文章已同步至【个人博客】，欢迎访问【我的主页】😃

文章地址：blog.fanjunyang.zone/archives/do…

前言

今天有一个妹纸向我提出了一个问题

是时候"出手"了，本着助人为乐的精神，这个忙必须帮（没办法，我就喜欢帮助别人）

现在我们在下载一些比如：Bilibili，YouTube等第三方视频的时候，还是比较困难的，需要找各种下载器和网站，而且还不一定能下载，一些免费好用的下载网站还不好找。
所以我们可以自己动手搭一个下载站点，来下载各大平台上的视频。

搭建的站点(大家轻点薅)：dl.junyang.space/

站点的地址会随着时间更新，如果上面的地址不能访问的话，大家可以去我的 博客 ，我会把站点入口放在【顶部菜单栏】->【百宝箱】里面)

相关链接&环境配置

最好用国外的服务器，如果用国内的服务器，是下载不了YouTube等需要魔法网站的视频的

docker、docker-compose安装：blog.fanjunyang.zone/archives/de…
Nginx Proxy Manager安装使用：blog.fanjunyang.zone/archives/ng…

使用的GitHub的开源项目：github.com/Rudloff/all…

使用的Docker镜像：hub.docker.com/r/dnomd343/…

搭建方式

创建相关目录

mkdir -p /root/docker_data/alltube

cd /root/docker_data/alltube

创建yml文件

version: '3.3'

services:

    alltube:

        restart: always

        container_name: alltube

        environment:

            # 自己网站的title

            - 'TITLE=My Alltube Site'

            - CONVERT=ON

            - STREAM=ON

            - REMUX=ON

        ports:

            # 左侧端口号换成你服务器上未使用的端口号

            - '24488:80'

        image: dnomd343/alltube

运行yml文件

进入/root/docker_data/alltube文件夹下面，运行命令：docker-compose up -d

或者在任意文件夹下面，运行命令：docker-compose -f /root/docker_data/alltube/docker-compose.yml up -d

访问使用

可以直接使用【IP + PORT】的方式访问（需要放通对应端口号的防火墙或安全组）

最好配置反向代理，用域名访问，可以参考：blog.fanjunyang.zone/archives/ng…

她对我说

当我把下载链接发给她时，她说：你真是个好人，正好我让我男朋友也用一下。

我不能忍，然后我默默的把站点删除、下线，眼里留下了悔恨的泪水。

注意事项&问题

• 目前解析不出来B站的视频封面（YouTube可以正常解析），不过不影响下载


• 因为B站音视频是分开的，所以需要下载两次（一次视频、一次音频），然后整合一下就好了


• 因国内版权限制的原因，部分资源无法解析是正常现象


• 下载的时候可以选择视频格式

腾小云导读

PC Web 端、手机 H5 端、小程序端、App 安卓端、App iOS 端......在多端时代，一个应用往往需要支持多端。若每个端都独立开发一套系统来支持，将消耗巨大的人力和经费！腾讯视频团队想到一个“偷懒”的方法——能不能只开发一套基础系统，通过兼容不同平台的特性，来快速编译出不同平台的应用呢？本篇特邀腾讯视频团队为你分享快速编译出支持多端的应用、一套代码行走天下的“偷懒”历程。欢迎阅读。

目录

1 背景

2 设计思路

3 具体实现

4 总结

01、 背景

腾讯视频搜索在多个端都存在：安卓 App 端搜索、iOS App 端搜索、H5 端搜索、小程序端搜索、PC Web 端、PC 客户端搜索。每个端，除了个别模块的样式有细微差异之外，其他都一样，如下面的图片所示。

按照以前的现状，安卓 App 端搜索一套代码、iOS App 端搜索一套代码、手机 H5 端一套代码、小程序端搜索一套代码、PC 客户端一套代码、PC Web 端一套代码......每套代码都是独立开发，独立维护，成本非常高。并且，后端的搜索接口以前也是分散在多个不同的协议中，有的平台是 jce 协议的接口，有的是 PB 协议的接口，也是五花八门。

随着业务增长的需求，我们已经没有足够的时间来维护各自一套独立的系统，我们打算进行升级改革！治理的办法就是：收敛！把后端不同平台的接口都归一到同一个接口中，通过平台号来区分；前端也将不同平台的代码，收敛归一成一套代码，通过条件编译来兼容适配不同平台的差异性，不同的平台，在蓝盾流水线中配置不同的参数来上线，从而达到多合一的效果。

总体来说，我们团队就实现一个“多端合一的万能模板”的想法达成一致。并且，我们希望使用 hippy-vue 技术栈。

理由有以下：

02、设计思路

系统的架构图如下所示：

通用模版为了简化开发、提高开发效率，在模版中集成了大量现有组件和工具包，具体可以分为以下三层：

• 第三方工具层

在通用工具库中，模版包装并提供了很多常用方法，比如 cookie 的设置和 cookie 的获取方法；DOM 的操作方法；Cache 的设置，Cache 的获取，Cache 的过期时间等。在第三方接入库中，模版已经接好了 Aegis 监控，Tab 实验的实验值获取，大同上报等；在打包编译库中，模版提供了通用的 Hippy App 打包安卓脚本和 IOS 脚本、H5 的打包脚本、小程序地打包脚本、一套代码，运行不同的打包命令，执行不同的编译打包脚本，就可以生成不同平台对应的发布包。编译打包在后续还会详细讲解。

• 数据管理层

在这层中，模版集成了跟数据处理相关的模块。

在 Store 层，由于该模块是基于 Vue2 实现的（Vue3 会在下一个版本中提供），模版已经集成好了 Vuex、State、Getters、Mutations、Actions 等，并且都有实例代码（该模版是基于 Vue2 实现的，Vue3 会在下一个版本中提供）；

在 Model 层，模版提供了一套将 PB 文件转化为 TS 类文件的方法，方便快速接入后端PB协议接口请求；同时，还包装了接口通用请求方法，以及全局的统一错误处理上报方法；在数据配置中，模版提供了全局的常量配置文件，应用的版本配置文件（版本的配置对 Hippy App 的应用非常实用），以及 UI 样式的配置（正常模式样式还是暗黑模式样式，宽屏，窄屏等）。

• UI 层

为了提高开发速度，提高开发效率，模版提供了示例页面代码。同时，根据脚手架来选择是否需要路由，来动态添加应用的路由；以及常用的基础组件库。这些组件库中的组件，是从众多 Hippy 应用中提取出来，实用又高效。

03、具体实现

本文将从 Hippy App 端实现，Hippy H5 端的实现和 Hippy 微信小程序端端实现来分别展开介绍。

下图是 Hippy App 端实现逻辑。

App 端的入口文件为 main-native.ts。在里面，声明了一个 App 实例，指定 phone 下的一些属性设置，比如状态栏、背景色等等。同时，需要用到的 native 组件，都需要在 main-native 中进行声明绑定，才可以在页面中使用。

例如：下图示例中注册声明了两个 native 组件，LottieView 和 VideoView，在页面中就可以直接使用这两个 native 组件。

Vue.registerElement('LottieView');

Vue.registerElement('VideoView', {

  component: {

    name: 'VideoView',

    processEventData(event: any, nativeEventName: string, nativeEventParams: any) {

      // To do something for the native component event

      return event;

    },

  },});

main-native 中还有一个重要的方法：app.$start() 方法。

该方法为 Hippy 引擎初始化完成后回调到 Hippy 前端的方法；Hippy 端跟 App 方法进行通信，通过 jsbridge 来进行，模版中已经封装好了具体方法；Hippy 请求后端接口，通过 fetch 协议，也有具体的协议方法封装；Hippy 在 App 内部的跳转，是通过伪协议跳转来实现的。

Hippy App 应用的部署分为以下三种情况：

• 本地调试

本地调试是通过 Hippy + Chrome Devtools 来完成，通过 WS 通道转发消息，具体流程如下图。

• 部署测试环境

模版中引入了环境变量参数，同时在代码模版中做了大量环境变量的兼容逻辑，比如测试环境用测试环境的接口，正式环境用正式环境的接口；测试环境用测试环境的 CDN，静态文件上传到测试环境，测试环境部署测试环境的离线包等；测试环境的调试我们是通过离线包的方式来实现的，有专门的测试环境流水线接入使用，只需要稍微做少许调整即可，有需要的可以私聊。

• 部署正式环境

正式环境流程会做这样几件事情：正式环境接口、正式环境的 CDN、正式环境的日志上、部署正式环境的离线包平台、图片的特殊处理。因为 App 端是采用离线包的形式，如果所有本地图片都打包到离线包中，会导致离线包包体积很大，会影响到 App 的整体体积大小和离线包的下载速度。模版中做了针对图片的特殊脚本处理：引入了图片编译大小变量：STATIC_SIZE_LIMIT。当大于该限制条件的图片都一律上传到 CDN，如果想保留的，则需要增加特殊声明：inline。

具体流程如下图所示：

Hippy H5 的实现流程如下图所示。

Hippy H5 的实现跟 App 的实现流程类似，但是差异如下：

这里重点讨论一下大同上报的实现。大同上报在 App 端的上报参数声明跟 H5 端的上报参数声明不一致，如何统一这些差异？模版中的解决方案是：封装自定义标签 Directive。

具体实现如下：在 Directive 标签中兼容 App 和 H5 的不一致。

/**

* @example

*

* <element v-report="elementReportInfo" />

* <element v-report="{ eid, ...extra }" />

* <page v-report="{ pgid, ...extra }" />

* <page v-report.page="assertPageReport" />

*/



Vue.directive('report', {

  bind(el) {

    el.addEventListener('layout', throttledForceReport);

  },

  unbind(el) {

    el.removeEventListener('layout', throttledForceReport);

  },

  inserted: setReport,

  update: setReport,

} as DirectiveOptions);

很多人可能会问，Hippy App 跟 Hippy H5 有很多不同的地方，如果写两套代码，会不会导致代码的体积变得很大？答案是一定的，为了解决以上问题，该万能模版提供了条件编译。引入环境变量：isNative。然后，根据该条件，进行条件编译，不同的平台，生成不同平台的代码，避免了生成大量冗余代码。

Hippy 微信小程序的实现流程如下图所示：

小程序的实现是基于 Taro Vue 框架。该框架跟 Hippy Vue 框架天然兼容，但是也有一些小程序的特殊地方：

为了一套代码能够同时支持 App，H5 和微信小程序，需要遵循一些约定的规范，否则在从 Hippy Vue 转化为 Taro Vue 的时候会遇到一些问题：

04、总结

目前该模版已经在腾讯视频的搜索场景落地，并且上线应用，但是，还是有一些需要共同打磨的地方：

Vue3 的支持：目前我们是基于 Hippy Vue2 来实现的。随着 Vue3 的广泛应用，后续我们需要升级到 Vue3。

组件丰富：通用组件的种类还不是特别丰富，只是基于我们腾讯视频搜索场景进行的封装，后续可以补充更多更丰富的组件。

迭代升级：通用组件目前还是通过源代码的方式存放在代码模版中，不利于后续组件的升级迭代。计划后续会把组件给迁移到我们的应用组件库平台 Athena，该平台我们会后续发专文介绍，大家敬请期待。

以上是本次分享全部内容，如果觉得文章还不错的话欢迎分享~

-End-

原创作者｜熊才刚

技术责编｜陈恕胜

你有什么开发提效小技巧？欢迎在腾讯云开发者公众号评论区中分享你的经验和看法。我们将选取1则最有意义的分享，送出腾讯云开发者-文化衫1件（见下图）。6月21日中午12点开奖。

面试经历

（后来别人跟我说这种写法nacos里也常见）

记录一次面试经历

2023.06.01

美团海笔的，本来以为笔的情况也不咋好 看到牛客网上一堆ak说没面试机会的

结果也不知怎地到了一面

（略过自我介绍和项目介绍~）

面试官：会写单例吗，写个单例看看

我：

// 饿汉式

public class SingleObject {

   private static SingleObject instance = new SingleObject();

 

   //让构造函数为 private

   private SingleObject(){}



   public static SingleObject getInstance(){

      return instance;

   }

}

面试官：嗯 你这个单例在没有引用的时候就创建了对象？优化一下

我：应该是懒汉模式！

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        // 多了一个判断是否为null的过程

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：你这个线程不安全啊 再优化一下？

我：那就加个锁吧

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

    public static synchronized Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

面试官：这种写法 多线程来了的话会阻塞在一起 能否再优化？

我：。。。 不会了

面试官：回去看看双检锁单例

···

之后问了数据库事务

1. 读未提交（read uncommitted）


2. 读已提交（read committed）


3. 可重复读（repeatable read）


4. 序列化（serializable）以及默认是哪个（repeatable read） 、

数据库的范式了解吗 等等

不出意外：

还是非常可惜的 这次机会 再加油吧

单例模式整理

学习自菜鸟教程

1.饿汉式

懒加载 no
多线程安全 yes
缺点：没有实现懒加载，即还未调用就创建了对象

public class Singleton {  

    private static Singleton instance = new Singleton();  

    private Singleton (){}  

    public static Singleton getInstance() {  

    return instance;  

    }  

}

2.懒汉式（线程不安全）

懒加载 yes
多线程安全 no

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

3.懒汉式（线程安全）

懒加载 yes
多线程安全 yes
缺点：和面试官说的那样，多线程访问会阻塞

public class Singleton {  

    private static Singleton instance;  

    private Singleton (){}  

  

    public static Singleton getInstance() {  

        if (instance == null) {  

            instance = new Singleton();  

        }  

        return instance;  

    }  

}

4.双检锁/双重校验锁（DCL，即 double-checked locking）

public class Singleton {  

    private volatile static Singleton singleton;  

    private Singleton (){}  

    public static Singleton getSingleton() {  

    if (singleton == null) {  

        synchronized (Singleton.class) {  

            if (singleton == null) {  

                singleton = new Singleton();  

            }  

        }  

    }  

    return singleton;  

    }  

}

这段代码是一个单例模式的实现，使用了双重检查锁定的方式来保证线程安全和性能。双重检查锁定是指在加锁前后都进行了一次判空的操作，以避免不必要的加锁操作。

而为了保证双重检查锁定的正确性，需要使用volatile关键字来修饰singleton变量，以禁止指令重排序优化。（JUC的知识串起来了！）如果没有volatile关键字修饰，可能会出现一个线程A执行了new Singleton()但是还没来得及赋值给singleton，而此时另一个线程B进入了第一个if判断，判断singleton不为null，于是直接返回了一个未初始化的实例，导致程序出错。

使用volatile关键字可以确保多线程环境下的可见性和有序性，即一个线程修改了singleton变量的值，其他线程能够立即看到最新值，并且编译器不会对其进行指令重排序优化。这样就能够保证双重检查锁定的正确性。

学到了 ！！！

后来别人提醒：

（牛逼。。）

5.登记式/静态内部类

public class Singleton {  

    private static class SingletonHolder {  

    private static final Singleton INSTANCE = new Singleton();  

    }  

    private Singleton (){}  

    public static final Singleton getInstance() {  

        return SingletonHolder.INSTANCE;  

    }  

}

这段代码是一个单例模式的实现，使用了静态内部类的方式来保证线程安全和性能。静态内部类是指在外部类中定义一个静态的内部类，该内部类可以访问外部类的所有静态成员和方法，但是外部类不能访问内部类的成员和方法。

在这个单例模式的实现中，SingletonHolder就是一个静态内部类，它里面定义了一个静态的、final的、类型为Singleton的变量INSTANCE。由于静态内部类只有在被调用时才会被加载，因此INSTANCE对象也只有在getInstance()方法被调用时才会被初始化，从而实现了懒加载的效果。

由于静态内部类的加载是线程安全的，因此不需要加锁就可以保证线程安全。同时，由于INSTANCE是静态final类型的，因此保证了它只会被实例化一次，并且在多线程环境下也能正确地被发布和共享。

这种方式相对于双重检查锁定来说更加简单和安全，因此在实际开发中也比较常用。

6. 枚举

public enum Singleton {  

    INSTANCE;  

    public void whateverMethod() {  

    }  

}

这段代码是使用枚举类型实现单例模式的一种方式。在Java中，枚举类型是天然的单例，因为枚举类型的每个枚举值都是唯一的，且在类加载时就已经被初始化。

在这个示例代码中，Singleton是一个枚举类型，其中只定义了一个枚举值INSTANCE。由于INSTANCE是一个枚举值，因此它在类加载时就已经被初始化，并且保证全局唯一。在使用时，可以通过Singleton.INSTANCE来获取该单例对象。

需要注意的是，虽然枚举类型天然的单例特性可以保证线程安全和反序列化安全，但是如果需要延迟初始化或者有其他特殊需求，仍然需要使用其他方式来实现单例模式。

7. 容器式单例

Java中可以使用容器来实现单例模式，比如使用Spring框架中的Bean容器。下面是一个使用Spring框架实现单例的示例代码：

1. 定义一个单例类，比如MySingleton：

public class MySingleton {

    private static MySingleton instance;

    private MySingleton() {}

    public static MySingleton getInstance() {

        if (instance == null) {

            instance = new MySingleton();

        }

        return instance;

    }

    public void doSomething() {

        // do something

    }

}

2. 在Spring的配置文件中定义该类的Bean：

<bean id="mySingleton" class="com.example.MySingleton" scope="singleton"/>

3. 在Java代码中获取该Bean：

ApplicationContext context = new ClassPathXmlApplicationContext("spring-config.xml");

MySingleton mySingleton = (MySingleton) context.getBean("mySingleton");

mySingleton.doSomething();

在上面的代码中，我们在Spring的配置文件中定义了一个名为mySingleton的Bean，它的类是com.example.MySingleton，作用域为singleton（即单例）。然后在Java代码中，我们通过ApplicationContext获取该Bean，并调用它的doSomething()方法。

使用Spring框架可以方便地管理单例对象，同时也可以很容易地实现依赖注入和控制反转等功能。

总结完成 继续加油！！！

你好，我是悟空。

最近生产环境遇到一个问题：

现象：创建工单、订单等地方，全都创建数据失败。

初步排查：报错信息为duplicate key，意思是保存数据的时候，报主键 id 重复，而这些 id 都是由雪花算法生成的，按道理来说，雪花算法是生成分布式唯一 ID，不应该生成重复的 ID。

大家可以先猜猜是什么原因。

有的同学可能对雪花算法不熟悉，这里做个简单的说明。

一、雪花算法

snowflake（雪花算法）：Twitter 开源的分布式 id 生成算法，64 位的 long 型的 id，分为 4 部分：

• 1 bit：不用，统一为 0


• 41 bits：毫秒时间戳，可以表示 69 年的时间。


• 10 bits：5 bits 代表机房 id，5 个 bits 代表机器 id。最多代表 32 个机房，每个机房最多代表 32 台机器。


• 12 bits：同一毫秒内的 id，最多 4096 个不同 id，自增模式

优点：

• 毫秒数在高位，自增序列在低位，整个ID都是趋势递增的。


• 不依赖数据库等第三方系统，以服务的方式部署，稳定性更高，生成ID的性能也是非常高的。


• 可以根据自身业务特性分配bit位，非常灵活。

缺点：

• 强依赖机器时钟，如果机器上时钟回拨（可以搜索 2017 年闰秒 7:59:60），会导致发号重复或者服务会处于不可用状态。

看了上面的关于雪花算法的简短介绍，想必大家能猜出个一二了。

雪花算法和时间是强关联的，其中有 41 位是当前时间的时间戳，

二、排查

2.1 雪花算法有什么问题？

既然是雪花算法的问题，那我们就来看下雪花算法出了什么问题：

（1）What：雪花算法生成了重复的 ID，这些 ID 是什么样的？

（2）Why：雪花算法为什么生成了重复的 key

第一个问题，我们可以通过报错信息发现，这个重复的 ID 是 -1，这个就很奇怪了。一般雪花算法生成的唯一 ID 如下所示，我分别用二进制和十进制来表示：

十进制表示：2097167233578045440



二进制表示：0001 1101 0001 1010 1010 0010 0111 1100 1101 1000 0000 0010 0001 0000 0000 0000

找到项目中使用雪花算法的工具类，生成 ID 的时候有个判断逻辑：

当当前时间小于上次的生成时间就会返回 -1，所以问题就出在这个逻辑上面。(有的雪花算法是直接抛异常)

if (timestamp < this.lastTimestamp) {

   return -1;

}

由于每次 timestamp 都是小于 lastTimeStamp，所以每次都返回了 -1，这也解释了为什么生成了重复的 key。

2.2 时钟回拨或跳跃

那么问题就聚焦在为什么当前时间还会小于上次的生成时间。

下面有种场景可能发生这种情况：

首先假定当前的北京时间是 9:00:00。另外上次生成 ID 的时候，服务器获取的时间 lastTimestamp=10:00:00，而现在服务器获取的当前时间 timestamp=09:00:00，这就相当于服务器之前是获取了一个未来时间，现在突然跳跃到当前时间。

而这种场景我们称之为时钟回拨或时钟跳跃。

时钟回拨：服务器时钟可能会因为各种原因发生不准，而网络中会提供 NTP 服务来做时间校准，因此在做校准的时候，服务器时钟就会发生时钟的跳跃或者回拨问题。

2.3 时钟同步

那么服务器为什么会发生时钟回拨或跳跃呢？

我们猜测是不是服务器上的时钟不同步后，又自动进行同步了，前后时间不一致。

首先我们的每台服务器上都安装了 ntpdate 软件，作为 NTP 客户端，会每隔 10 分钟向 NTP 时间服务器同步一次时间。

如下图所示，服务器 1 和 服务器 2 部署了应用服务，每隔 10 分钟向时间服务器同步一次时间，来保证服务器 1 和服务器 2 的时间和时间服务器的时间一致。

每隔 10 分钟同步的设置：

*/10 * * * * /usr/sbin/ntpdate <ip>

另外时间服务器会向 NTP Pool同步时间，NTP Pool 正在为世界各地成百上千万的系统提供服务。 它是绝大多数主流Linux发行版和许多网络设备的默认“时间服务器”。（参考ntppool.org）

那问题就是 NTP 同步出了问题？？

2.4 时钟不同步

我们到服务器上查看了下时间，确实和时钟服务器不同步，早了几分钟。

当我们执行 NTP 同步的命令后，时钟又同步了，也就是说时间回拨了。

ntpdate  <时钟服务器 IP>

在产生事故之前，我们重启过服务器 1。我们推测服务器重启后，服务器因网络问题没有正常同步。而在下一次定时同步操作到来之前的这个时间段，我们的后端服务已经出现了因 ID 重复导致的大量异常问题。

这个 NTP 时钟回拨的偶发现象并不常见，但时钟回拨确实会带了很多问题，比如润秒 问题也会带来 1s 时间的回拨。

闰秒就是通过给“世界标准时间”加（或减）1秒，让它更接近“太阳时”。例如，两者相差超过0.9秒时，就在23点59分59秒与00点00分00秒之间，插入一个原本不存在的“23点59分60秒”，来将时间调慢一秒钟。

为了预防这种情况的发生，网上也有一些开源解决方案。

三、解决方案

（1）方式一：使用美团 Leaf方案，基于雪花算法。

（2）方式二：使用百度 UidGenerator，基于雪花算法

（3）方式三：用 Redis 生成自增的分布式 ID。弊端是 ID 容易被猜到，有安全风险。

3.1 美团的 Leaf 方案

美团的开源项目 Leaf 的方案：采用依赖 ZooKeeper 的数据存储。如果时钟回拨的时间超过最大容忍的毫秒数阈值，则程序报错；如果在可容忍的范围内，Leaf 会等待时钟同步到最后一次主键生成的时间后再继续工作。

重点就是需要等待时钟同步！

3.2 百度 UidGenerator 方案

百度UidGenerator方案不在每次获取 ID 时都实时计算分布式 ID，而是利用 RingBuffer 数据结构，通过缓存的方式预生成一批唯一 ID 列表，然后通过 incrementAndGet() 方法获取下一次的时间，从而脱离了对服务器时间的依赖，也就不会有时钟回拨的问题。

重点就是预生成一批 ID！

Github地址：

https://github.com/baidu/uid-generator

四、总结

本篇通过一次偶发的生产事故，引出了雪花算法的原理、雪花算法的不足、对应的开源解决方案。

雪花算法强依赖服务器的时钟，如果时钟产生了回拨，就会造成很多问题。

我们的系统虽然做了 NTP 时钟同步，但也不是 100% 可靠，而且润秒这种场景也是出现过很多次。鉴于此，美团和百度也有对应的解决方案。

最后，我们的生产环境也是第一次遇到因 NTP 导致的时钟回拨，而且系统中用到雪花算法的地方并不多，所以目前并没有采取以上的替换方案。

https://github.com/Jackson0714/PassJava-Platform/blob/master/passjava-common/src/main/java/com/jackson0714/passjava/common/utils/SnowflakeUtilV2.java

参考资料：

time.geekbang.org/dailylesson…

blog.csdn.net/liangcsdn11…

http://www.jianshu.com/p/2911