你是否厌倦了代码中难以阅读和维护的冗长 try-catch 代码块？全新的 ECMAScript 安全赋值运算符 (?= ) 将彻底改变游戏规则！这一突破性的特性简化了错误处理，让你的代码更简洁、更高效。让我们深入了解 ?= 运算符如何彻底改变你的编码体验！

简化代码，轻松处理错误

告别嵌套的 try-catch 混乱

问题： 传统的 try-catch 代码块会导致代码深度嵌套，难以理解和调试。

解决方案： 使用 ?= 运算符，你可以将函数结果转换为一个元组，更优雅地处理错误。如果出现错误，你将得到 [error, null] ，如果一切正常，你将得到 [null, result] 。你的代码将会感谢你！

使用 ?= 之前：

async function fetchData() {

  try {

    const response = await fetch("https://api.example.com/data");

    try {

      const data = await response.json();

      return data;

    } catch (parseError) {

      console.error('Failed to parse JSON:', parseError);

    }

  } catch (networkError) {

    console.error('Network error:', networkError);

  }

}

使用 ?= 之后：

async function fetchData() {

  const [networkError, response] ?= await fetch("https://api.example.com/data");

  if (networkError) return console.error('Network error:', networkError);

  const [parseError, data] ?= await response.json();

  if (parseError) return console.error('Failed to parse JSON:', parseError);

  return data;

}

提升代码清晰度：保持代码线性，简洁易懂

问题： try-catch 代码块会打断代码流程，降低可读性。

解决方案： ?= 运算符使错误处理变得简单直观，保持代码线性，易于理解。

示例：

const [error, result] ?= await performAsyncTask();

if (error) handleError(error); 

标准化错误处理：跨 API 保持一致性

问题： 不同的 API 通常需要不同的错误处理方法，导致代码不一致。

解决方案： ?= 运算符提供了一种统一的错误处理方式，使你的代码在各种 API 中保持一致。

提升安全性：每次都捕获所有错误

问题： 漏掉错误会导致 bug 和潜在的安全问题。

解决方案： ?= 运算符确保始终捕获错误，降低漏掉关键问题的风险。

Symbol.result 背后的奥秘

自定义错误处理变得简单

概述： 实现 Symbol.result 方法的对象可以使用 ?= 运算符定义自己的错误处理逻辑。

示例：

function customErrorHandler() {

  return {

    [Symbol.result]() {

      return [new Error("Custom error message"), null];

    },

  };

}



const [error, result] ?= customErrorHandler();

轻松处理嵌套错误：平滑处理复杂场景

概述： ?= 运算符可以处理包含 Symbol.result 的嵌套对象，使复杂错误场景更容易管理。

示例：

const complexObj = {

  [Symbol.result]() {

    return [

      null,

      { [Symbol.result]: () => [new Error("Nested error"), null] }

    ];

  },

};



const [error, data] ?= complexObj;

与 Promise 和异步函数无缝集成

概述： ?= 运算符专门设计用于与 Promise 和 async/await 无缝协作，简化异步错误处理。

示例：

const [error, data] ?= await fetch("https://api.example.com/data");

使用 using 语句简化资源管理

概述： 将 ?= 运算符与 using 语句结合使用，可以更有效地管理资源。

示例：

await using [error, resource] ?= getResource();

优先处理错误：先处理错误，后处理数据

概述： 将错误放在 [error, data] ?= 结构的第一个位置，确保在处理数据之前先处理错误。

示例：

const [error, data] ?= someFunction();

让你的代码面向未来：简化填充

概述： 虽然无法直接填充 ?= 运算符，但你可以使用后处理器在旧环境中模拟其行为。

示例：

const [error, data] = someFunction[Symbol.result]();

汲取灵感：从 Go、Rust 和 Swift 中学习

概述： ?= 运算符借鉴了 Go、Rust 和 Swift 等语言的先进错误处理实践，这些语言以其强大的错误管理功能而闻名。

当前限制和未来方向

仍在发展： ?= 运算符仍在开发中。改进领域包括：

• 命名： 为实现 Symbol.result 的对象提供更好的术语。


• finally 代码块： 没有新的 finally 代码块语法，但传统用法仍然有效。

总结

安全赋值运算符 (?= ) 将通过使 JavaScript 错误处理更加直观和简洁来彻底改变 JavaScript 错误处理。随着该提案的不断发展，它将有望成为每个 JavaScript 开发人员工具箱中的必备工具。准备迎接更干净、更安全的代码吧！🚀

 5. 第一次代码真正预上线之后，此后更新代码再发布新的包，一半就只需要1~2天

开发过程

先在微信公众号平台开通消息订阅模板，拿到模板ID，前端中再调用 uni.requestSubscribeMessage 传入拿到的模板ID就可以实现消息订阅

5. webSocket。小程序中的树洞评论功能我们选用的是webSocket，小程序中我们没有使用三方库，调用的是uniapp的uni.connectSocket，创建一个webSocket实例，然后处理对应的回调。由于用户一段时间内如果不发送消息，服务端也就没东西推送过来，webSocket自己会断掉。所以我们引入了心跳机制和断线重连机制。但是在做短信重连的时候就发现一个问题：断线重连之后确实是会创建新的实例，心跳包也正常推送给服务端，但是就是接收不到服务端反推回来的东西，后面经过排查，是webSocket实例的onMessage事件应当写在onOpen中，而不是独立写到外面

独立写到外面进行处理就会出现：断线重连之后死活接不到最新的实例返回的消息

这里再次吐槽微信的内容审核机制。原先选用webSocket的原因就是看中了它的实时推送，但是接入了内容审核就变得很抽象，时而秒通过，时而得等一下，这也搞得失去了选用webSocket的意义

6. 请求池。小程序中使用到了tabs组件，当tab在切换过程中，比如tabA切换至tabB，由于需要请求数据，所以页面会有短暂的白屏时间，这里采用的是请求池，在获取第一个tab的列表数据的时候，由请求池顺便把之后的tab的内容也请求回来，此后在进行tab切换时就可以避免白屏，优化用户体验

7. 响应式布局。小程序在个人页模仿了小红书个人页的实现形式，也就是随着页面的滚动，页面的布局（主要是用户头像缩小并由透明度为0逐渐变为1）发生变化。一开始采用的是监听页面scroll事件。但是，scroll涉及大量的计算；后面采用Intersection Observer。但是注意，uniapp不能直接使用这个API，得调用uni.createIntersectionObserver，二者语法差不多
8. 防抖节流的使用。页面滚动加载下一页使用防抖，按钮点击进行节流，常规操作。

大概暂时先能想到这么多，后面有想到再接着补充......

后记

其实校园小程序这个题材市面上早已烂大街，说不上有任何的创新。此前决定搞这个的原因有以下几点：

然后整一个项目跟下来吧，给我的感觉就是：技术重要吗？重要；但也不太重要，技术的重要性就跟我这句废话一样。因为一个东西，推广不起来，没人用，你就没动力去更新、去维护。当然，有没有人用对我们此次的开发来说还不算是必选项。

大家觉得校园社交类的程序还能集成什么功能，也欢迎提出您的宝贵意见

背景

某天夜里，你正睡着觉，与周公神游。

老板打来电话：“小李，快看一下，系统出故障了，一个小时发了200条短信，再搞下去，我要破产了..."

巴拉巴拉...

于是，你赶紧跳下床，查了一个后台日志，发送短信API接口5s发送一次，都已经发送了500条了。在达到每日限额后，自动终止了。很明显被黑客攻击了。

500 * 0.1 * 8 = 400

一晚上约干掉了400元人民币

睡意全无，赶紧起来排查原因

故障分析

我司是做国外业务的，用的短信厂家是RingRing, 没有阿里云那种自带的强悍的预警和封禁功能。黑客通过伪造IP地址和手机号然后攻破了APP的短信接口，然后顺藤摸瓜的拿到相关发布的全部应用。于是，一个晚上，单个APP的每日短信限额和全部短信限额都攻破了。

APP使用的是https双向加密，黑客也不是单纯的爆破，没有大量的验证码错误日志。我们现在都不清楚黑客是通过什么方式绕过我们系统的，或者直接攻破了验证码

可能有懂这方面的掘友，可以分享一下哈

我们先上了一个临时方案，如果10分钟内，发送短信超过30条，且手机号超过60%都是同一个国家，我们关闭短信发送功能10分钟，并推送告警

然后抓紧时间去升级验证码，提高安全标准

验证码

文字验证码

我司最开始用的就是这种，简单易用。但是任你把噪点和线条铺满，整的面目全非，都防不住机器的识别，这种验证码直接pass了

优点：简易，具有一定的防爆破功能

缺点：防君子不防小人，在黑客面前，GG

滑块验证码

我司对于滑块验证码有几点考虑：

基于这几点考虑，我司放弃了这个方案。但平心而论，国内用滑块验证码的是最多的，原因如下：

npm install rc-slider-captcha



import SliderCaptcha from 'rc-slider-captcha';



const Demo = () => {

  return (

    <SliderCaptcha

      request={async () => {

        return {

          bgUrl: 'background image url',

          puzzleUrl: 'puzzle image url'

        };

      }}

      onVerify={async (data) => {

        console.log(data);

        // verify data

        return Promise.resolve();

      }}

    />

  );

};

滑块验证码是用的最多的验证码，操作简单，基本平替了图片验证码

图形顺序验证码 & 图形匹配验证码 & 语顺验证码

我司没有采用这种方案的原因如下：

总结：

安全性更强，用户量越大的网站越受青睐

难度相对更大，频繁验证会流失一些用户

reCAPTCHA v3

综上，我司使用了reCAPTCHA

理由如下：

<script src="https://www.google.com/recaptcha/api.js?render=reCAPTCHA_site_key"></script>



<script>

  function onClick(e) {

    e.preventDefault();

    grecaptcha.ready(function() {

      grecaptcha.execute('reCAPTCHA_site_key', {action: 'submit'}).then(function(token) {

          // Add your logic to submit to your backend server here.

      });

    });

  }

</script>



// 返回值

{

  score: 1  // 评分0 到 1。1：确认为人类，0：确认为机器人。

  hostname: "localhost"  

  success: true,

  challenge_ts: "2024-xx-xTxx:xx:xxZ"

  action: "homepage"

}

紧急上线后，安全性大大增强，再也没有遭受黑客袭击了。本以为可以睡个安稳觉了，又有其他的问题了，听我细讲

根据官方文档，建议score取0.5, 我们根据测试的情况，降低了标准，设置为0.3。上线后，很多用户投诉安全度过低，请30分后重试。由于我们当时的业务是出行和游乐, APP受限后，用户生活受到了很大限制，很多用户预约了我们的产品，却用不了，导致收到了大量的投诉。更糟糕的时候，我们的评分标准0.3是写死的，只能重新发布，一来二去，3天过去了。客服被用户骂了后，天天来我们技术部骂我们。哎，想想都是泪

我们紧急发布了一版，将评分标准设置成可配置的，通过API获取, 暂定0.1。算是勉强度过了这一关

reCAPTCHA v2

把分数调整到0.1后，我们觉得不是很安全，有爆破的风险，于是在下个版本使用了v2

使用v2，一切相对平稳，APP短信验证码风波也算平安度过了

2FA

双因素验证(Two-factor authentication,简称2FA，又名二步验证、双重验证)，是保证账户安全的一道有效防线。在登录或进行敏感操作时，需要输入验证器上的动态密码（类似于银行U盾），进一步保护您的帐户免受潜在攻击者的攻击。双因素验证的动态密码生成器分为软件和硬件两种，最常用的软件有OTP Auth和谷歌验证器 (Google Authenticator)

经市场调用，客户要求，后续的APP，我们的都采用2fa方案，一人一码，安全可靠。

实现起来也比较简单，后端使用sha1加密一串密钥，生成哈希值，用户扫码绑定，然后每次将这个验证码提交给服务器进行比对即可

每次使用都要看一下验证码，感觉有点烦

服务器和手机进行绑定，是同一把密钥，每次输入都找半天。一旦用户更换手机，就必须生成全新的密钥。

总结

参考资料

动画在前端开发中是经常遇到的场景之一，加入动画后页面可以极大的提升用户体验。

绝大多数简单的动画场景可以直接通过CSS实现，对于一些特殊场景的动画可能会使用到JS计算实现，通过本文的学习，可以让你在一些看似需要使用JS实现的动画场景，使用纯CSS一样可以实现，并且更方便快捷。

先看一个简单的例子：一个方块的位置随着滑条滑动的位置改变

这个场景实现起来很简单，滑条值改变后，使用JS计算方块应该移动的距离，然后将方块定位到指定位置即可。代码如下：

.box {

height: 50px;

width: 50px;

    background-color: aquamarine;

}

<div class="box">div>

<input type="range" min="0" max="1" step="0.01"/>

现在稍微增加一些动画效果：

• 方块在中间位置时缩放为原来的一半大小


• 方块在中间位置时变成球形


• 方块从红色变为绿色

对于大小和圆角，同样可以使用简单的JS进行计算实现，但是对于颜色变化，使用JS计算将会是一个非常复杂的过程。

先抛开动画跟随滑条运动这个要求，如果使用CSS实现上面从0-1的动画过程是一个很简单的事：

.box {

height: 50px;

width: 50px;

background-color: aquamarine;

transform: translateX(0);

    animation: run 1s linear forwards;

}

@keyframes run {

    0% {

transform: translateX(0) scale(1);

border-radius: 0%;

background: red;

    }

    50% {

transform: translateX(100px) scale(.5);

border-radius: 50%;

    }

    100% {

transform: translateX(200px) scale(1);

border-radius: 0%;

background: green;

    }

}

利用CSS动画帮我们可以很轻松的计算出每个时间点时的状态，现在的问题就变成如何让动画停留在指定的时间点，这就需要使用到动画的两个属性：

annimation-play-state：设置动画是运行还是暂停，有两个属性值runing、paused
annimation-delay：设置动画开始时间的偏移量，如果是正值，则动画会延迟开始；如果是负值(-d)，动画会立即开始，开始位置在动画(d)s时所处的位置。

有了这两个属性，现在将上面的动画停留在50%的位置

假设整个动画过程需要1s，50%的位置则需要将延迟值设置为-0.5s，这样动画就会停留在0.5s的位置。

.box {

height: 50px;

width: 50px;

background-color: aquamarine;

transform: translateX(0);

animation: run 1s -0.5s linear forwards infinite paused;

}

接下来只需要将滑条的值与动画延迟的值关联起来即可，这里可以通过CSS变量来实现：

.box {

--duration: -0.5s;  // 定义延迟变量

height: 50px;

width: 50px;

background-color: aquamarine;

transform: translateX(0);

animation: run 1s var(--duration) linear forwards infinite paused;

}



@keyframes run {

    0% {

transform: translateX(0) scale(1);

border-radius: 0%;

background: red;

    }

    50% {

transform: translateX(100px) scale(.5);

border-radius: 50%;

    }

    100% {

transform: translateX(200px) scale(1);

border-radius: 0%;

background: green;

    }

}

应用场景

利用CSS延迟动画可以轻松实现很多交互场景，例如：跟随鼠标滚动界面发生反馈动画、根据当天时间界面从日出到日落、根据不同分值出现不同表情变化等等。

在业务运营中，倒计时功能是常见的需求，尤其是在限时秒杀等促销活动中。为了确保时间的精确性和一致性，推荐使用服务器时间作为倒计时的基准。那么，如何在前端实现一个既准确又用户友好的倒计时组件的计时逻辑呢？

传统计时器实现

传统计时器实现倒计时的核心原理很简单，它使用了 setInterval 或 setTimeout 的对计时信息进行更新。类似于如下代码：

import React, { useState, useEffect } from 'react';



const CountdownTimer: React.FC<{ duration: number }> = ({ duration }) => {

  const [secondsRemaining, setSecondsRemaining] = useState(duration);



  useEffect(() => {

    const intervalId = setInterval(() => {

      if (secondsRemaining > 0) {

        setSecondsRemaining(secondsRemaining - 1);

      } else {

        clearInterval(intervalId);

      }

    }, 1000);



    // 清理计时器

    return () => clearInterval(intervalId);

  }, [secondsRemaining]);



  return (

    <div>

      倒计时: {secondsRemaining} 秒

    </div>

  );

};



export default CountdownTimer;

上述代码实现很好地实现了倒计时逻辑，但是，还是存在一些问题。我们先来讨论一下浏览器事件循环关于延时队列的优先级。我们知道，为了有效地管理任务和事件，事件循环使用了一个队列系统。事件循环主要包含如下两个队列：

在事件循环中，当一个宏任务执行完毕后，JavaScript 引擎会先清空所有微任务队列中的所有任务，然后再去检查是否需要执行下一个宏任务。这意味着微任务的优先级高于宏任务。

setTimeout 或 setInterval 任务会在指定的延时后被加入到宏任务队列的末尾。当当前的宏任务执行完毕后，如果微任务队列不为空，JavaScript 引擎会先执行完所有微任务，然后才会执行下一个宏任务，也就是 setTimeout 或 setInterval 中的回调函数。因此，setTimeout 或 setInterval 的优先级是相对较低的，因为它们必须等待当前宏任务执行完毕以及所有微任务执行完毕后才能执行。

这种机制可能导致一个问题：如果页面上的其他微任务执行时间较长，倒计时显示可能会出现“跳秒”现象。例如，倒计时可能从 60 秒直接跳到 58 秒，而不是平滑地递减。

requestAnimationFrame 实现

针对上述“跳秒”问题，我们可以改用 requestAnimationFrame 去进行时间的更新逻辑执行。我们将上述代码修改为如下代码：

import React, { useState, useEffect } from 'react';



const CountdownTimer: React.FC<{ duration: number }> = ({ duration }) => {

  const [secondsRemaining, setSecondsRemaining] = useState(duration);



  useEffect(() => {

    let animationFrameId: number;



    const updateTimer = () => {

      if (secondsRemaining > 0) {

        setSecondsRemaining(prev => prev - 1);

        animationFrameId = requestAnimationFrame(updateTimer);

      } else {

        cancelAnimationFrame(animationFrameId);

      }

    };



    // 启动动画帧

    animationFrameId = requestAnimationFrame(updateTimer);



    // 清理动画帧

    return () => cancelAnimationFrame(animationFrameId);

  }, [secondsRemaining]);



  return (

    <div>

      倒计时: {secondsRemaining} 秒

    </div>

  );

};



export default CountdownTimer;

在编写倒计时功能的代码时，我们应当确保在每次更新倒计时秒数后重新启动动画帧。这样做可以避免在动画帧完成后，倒计时逻辑停止更新，导致倒计时在减少一秒后不再继续。同时，为了确保资源的有效管理，我们还需要提供一个函数来清理动画帧，这样当组件不再需要时，可以停止执行动画帧，避免不必要的性能消耗。通过这些措施，我们可以保证倒计时功能的准确性和组件的高效卸载。

优势

要深入理解 requestAnimationFrame 在实现倒计时中的优势，我们首先需要探讨一个问题：在 requestAnimationFrame 中直接修改 DOM 是否合适？requestAnimationFrame 是一个专为动画效果设计的 Web API，它通过在浏览器的下一次重绘之前调用回调函数，帮助我们创建更加流畅且高效的动画。与传统的定时器方法（如 setTimeout 和 setInterval）相比，requestAnimationFrame 提供了更优的性能和更少的资源消耗。

在 requestAnimationFrame 中修改 DOM 是合适的，尤其是当涉及到动画和视觉更新时。这是因为 requestAnimationFrame 的设计初衷就是为了优化动画性能，确保动画的流畅性和效率。总结来说，requestAnimationFrame 相较于传统的计时器方法，具有以下显著优势：

• 性能优化：通过在浏览器的下一次重绘前调用回调，确保动画的流畅性。


• 节能高效：当浏览器标签页不处于活跃状态时，requestAnimationFrame 会自动暂停，从而减少 CPU 的使用，延长设备电池寿命。


• 同步刷新：能够与浏览器的刷新率同步，有效避免动画中的跳帧现象。

因此，requestAnimationFrame 不仅适用于复杂的动画场景，也非常适合实现需要精确时间控制的倒计时功能，提供了一种更加高效和节能的解决方案。

劣势

尽管 requestAnimationFrame 在动画制作方面表现出色，但在实现倒计时功能时，它也存在一些局限性：

• 精确度问题：requestAnimationFrame 并不适用于需要严格时间控制的场景。因为它的调用时机依赖于浏览器的重绘周期，这可能导致时间间隔的不稳定性。


• 管理复杂性：使用 requestAnimationFrame 需要开发者手动管理动画状态和进行资源清理，这增加了实现的复杂度。

正因如此，许多现代前端框架和库，如 ahook 等，在选择实现倒计时功能时，倾向于采用传统的定时器（如 setTimeout 或 setInterval），而非 requestAnimationFrame。这些传统方法虽然可能不如 requestAnimationFrame 在动画性能上优化，但它们提供了更稳定和可预测的时间控制，这对于倒计时这类功能来说至关重要。

总结

实现一个倒计时组件的计时逻辑，我们有如下的一些建议：

总结来说，选择最合适的技术方案取决于你的具体需求。无论是 requestAnimationFrame 还是传统的定时器方法，都有其适用场景和优势。关键在于根据项目需求，做出明智的选择，以实现最佳的用户体验。

2024年3月10日

知识积累

为什么使用Kafka？

不使用Rabbitmq或者Rocketmq是因为Kafka是Hadoop集群下的组成部分，对于大数据的相关开发适应性好，且当前业务场景下不需要使用死信队列，不过要注意Kafka对于更新时间慢的数据拉取也较慢，因此对与实时性要求高可以选择其他MQ。
使用消息队列是因为该中间件具有实时性，且可以作为广播进行消息分发。

为什么使用SSE？

使用Websocket传输信息的时候，会转成二进制数据，产生一定的时间损耗，SSE直接传输文本，不存在这个问题
由于Websocket是双向的，读取日志的时候，如果有人连接ws日志，会发送大量异常信息，会给使用段和日志段造成问题；SSE是单向的，不需要考虑这个问题，提高了安全性
另外就是SSE支持断线重连；Websocket协议本身并没有提供心跳机制，所以长时间没有数据发送时，会将这个连接断掉，因此需要手写心跳机制进行实现。
此外，由于是长连接的一个实现方式，所以SSE也可以替代Websocket实现扫码登陆（比如通过SSE的超时组件在实现二维码的超时功能，具体实现我可以整理一下）
另外，如果是普通项目，不需要过高的实时性，则不需要使用Websocket，使用SSE即可

代码实现

Java代码

pom.xml引入SSE和Kafka

<!-- SSE，一般springboot开发web应用的都有 -->

       <dependency>

           <groupId>org.springframework.boot</groupId>

           <artifactId>spring-boot-starter-web</artifactId>

       </dependency>

<!-- kafka，最主要的是第一个，剩下两个是测试用的 -->

       <dependency>

            <groupId>org.springframework.kafka</groupId>

            <artifactId>spring-kafka</artifactId>

        </dependency>

        <dependency

            <groupId>org.springframework.kafka</groupId>

            <artifactId>spring-kafka-test</artifactId>

            <scope>test</scope>

        </dependency>

        <dependency>

            <groupId>org.apache.kafka</groupId>

            <artifactId>kafka-clients</artifactId>

            <version>3.4.0</version>

        </dependency>

application.properties增加Kafka配置信息

# KafkaProperties

spring.kafka.bootstrap-servers=localhost:9092

spring.kafka.consumer.group-id=community-consumer-group

spring.kafka.consumer.auto-offset-reset=earliest

spring.kafka.producer.value-serializer=org.apache.kafka.common.serialization.StringSerializer

spring.kafka.producer.key-serializer=org.apache.kafka.common.serialization.StringSerializer

配置Kafka信息

@Configuration

public class KafkaProducerConfig {



    @Value("${spring.kafka.bootstrap-servers}")

    private String bootstrapServers;



    @Bean

    public Map<String, Object> producerConfigs() {

        Map<String, Object> props = new HashMap<>();

        props.put(ProducerConfig.BOOTSTRAP_SERVERS_CONFIG, bootstrapServers);

        props.put(ProducerConfig.KEY_SERIALIZER_CLASS_CONFIG, StringSerializer.class);

        props.put(ProducerConfig.VALUE_SERIALIZER_CLASS_CONFIG, StringSerializer.class);

        return props;

    }



    @Bean

    public ProducerFactory<String, String> producerFactory() {

        return new DefaultKafkaProducerFactory<>(producerConfigs());

    }



    @Bean

    public KafkaTemplate<String, String> kafkaTemplate() {

        return new KafkaTemplate<>(producerFactory());

    }



}

配置controller，通过web方式开启效果

@RestController

@RequestMapping(path = "sse")

public class KafkaSSEController {



    private static final Map<String, SseEmitter> sseCache = new ConcurrentHashMap<>();



    @Resource

    private KafkaTemplate<String, String> kafkaTemplate;

    

    @Resource

    private SseEmitter sseEmitter;



    /**

     * @param message

     * @apiNote 发送信息到Kafka主题中

     */

    @PostMapping("/send")

    public void sendMessage(@RequestBody String message) {

        kafkaTemplate.send("my-topic", message);

    }



    /**

     * 监听Kafka数据

     *

     * @param message

     */

    @KafkaListener(topics = "my-topic", groupId = "my-group-id")

    public void consume(String message) {

        System.out.println("Received message: " + message);

        //使用接口建立起sse连接后，监听到kafka消息则会发送给对应链接

        SseEmitter sseEmitter = sseCache.get(id); if (sseEmitter != null) { sseEmitter.send(content); }

    }



    /**

     * 连接sse服务

     *

     * @param id

     * @return

     * @throws IOException

     */

    @GetMapping(path = "subscribe", produces = {MediaType.TEXT_EVENT_STREAM_VALUE})

    public SseEmitter push(@RequestParam("id") String id) throws IOException {

        // 超时时间设置为5分钟，用于演示客户端自动重连

        SseEmitter sseEmitter = new SseEmitter(5_60_000L);

        // 设置前端的重试时间为1s

        // send(): 发送数据，如果传入的是一个非SseEventBuilder对象，那么传递参数会被封装到 data 中

        sseEmitter.send(SseEmitter.event().reconnectTime(1000).data("连接成功"));

        sseCache.put(id, sseEmitter);

        System.out.println("add " + id);

        sseEmitter.send("你好", MediaType.APPLICATION_JSON);

        SseEmitter.SseEventBuilder data = SseEmitter.event().name("finish").id("6666").data("哈哈");

        sseEmitter.send(data);

        // onTimeout(): 超时回调触发

        sseEmitter.onTimeout(() -> {

            System.out.println(id + "超时");

            sseCache.remove(id);

        });

        // onCompletion(): 结束之后的回调触发

        sseEmitter.onCompletion(() -> System.out.println("完成！！！"));

        return sseEmitter;

    }

    /**

     * http://127.0.0.1:8080/sse/push?id=7777&content=%E4%BD%A0%E5%93%88aaaaaa

     * @param id

     * @param content

     * @return

     * @throws IOException

     */

    @ResponseBody

    @GetMapping(path = "push")

    public String push(String id, String content) throws IOException {

        SseEmitter sseEmitter = sseCache.get(id);

        if (sseEmitter != null) {

            sseEmitter.send(content);

        }

        return "over";

    }



    @ResponseBody

    @GetMapping(path = "over")

    public String over(String id) {

        SseEmitter sseEmitter = sseCache.get(id);

        if (sseEmitter != null) {

            // complete(): 表示执行完毕，会断开连接

            sseEmitter.complete();

            sseCache.remove(id);

        }

        return "over";

    }



}

前端方式

<html>

  <head>

    <script>

      console.log('start')

      const clientId = "your_client_id_x"; // 设置客户端ID

      const eventSource = new EventSource(`http://localhost:9999/v1/sse/subscribe/${clientId}`); // 订阅服务器端的SSE



      eventSource.onmessage = event => {

        console.log(event.data)

        const message = JSON.parse(event.data);

        console.log(`Received message from server: ${message}`);

      };



      // 发送消息给服务器端 可通过 postman 调用，所以下面 sendMessage() 调用被注释掉了

      function sendMessage() {

        const message = "hello sse";

        fetch(`http://localhost:9999/v1/sse/publish/${clientId}`, {

          method: "POST",

          headers: { "Content-Type": "application/json" },

          body: JSON.stringify(message)

        });

        console.log('dddd'+JSON.stringify(message))

      }

      // sendMessage()

    </script>

  </head>

</html>

抛出痛点

在分配任务时,我们将需求分为三个分支任务,分别由前端A、B、C负责:

相应地,我们创建三个功能分支:

• feature_HCC-111-实现登录功能


• feature_HCC-112-实现用户注册


• feature_HCC-113-实现用户删除

当所有的前端都开发完成了他们的任务，我们就要开始测试小程序了。但是如果按照以往体验版的测试方式，我们就需要排个顺序。比如，前端 A 先将他的小程序设置为体验版，测试把他的功能测试完成之后，再把前端 B 的设置为体验版，以此类推。可以看出真的很麻烦，而且浪费开发时间，我想你肯定不想在开发的时候突然被叫把你的小程序版本设置为体验版。

解决方案

小程序开发助手 这是一个官方提供的小程序，里面有多个版本的小程序可供选择，很方便测试人员的测试，并且也会节省开发人员的时间。点击版本查看就可以看到所有开发人员提交的最近的一次版本了。这样也不用设置体验版就可以测试最新的提交了。

再次抛出痛点

如果前端 A 头上有三个任务单呢？任务单：HCC-121-实现框架搭建，HCC-122-实现在线录屏，HCC-123-实现画板。此时你可能想说, 为啥前端 A 这么多的任务单呢？他命苦啊！

这个时候就需要配合微信的机器人了，我们可以创建多个机器人作为我们提交版本的媒介，这样我们就不受限于微信账号了。

可以在微信的官方文档看到 robot 参数有30个机器人可供选择。

接下来看下微信的机器人的使用方式。

miniprogram-ci文档

微信官方是这样介绍这个工具的; miniprogram-ci 是从微信开发者工具中抽离的关于小程序/小游戏项目代码的编译模块。它其实是一个自动上传代码的工具，可以帮助我们自动化的编译代码并且上传到微信。

下面是一个大概得使用的示例，具体还是要参考官方文档。

const ci = require('miniprogram-ci');

(async () => {

  const project = new ci.Project({

    appid: 'wxsomeappid',

    type: 'miniProgram',

    projectPath: 'the/project/path',

    privateKeyPath: 'the/path/to/privatekey',

    ignores: ['node_modules/**/*'],

  })

  const previewResult = await ci.preview({

    project,

    desc: 'hello', // 此备注将显示在“小程序助手”开发版列表中

    setting: {

      es6: true,

    },

    qrcodeFormat: 'image',

    qrcodeOutputDest: '/path/to/qrcode/file/destination.jpg',

    onProgressUpdate: console.log,

    // pagePath: 'pages/index/index', // 预览页面

    // searchQuery: 'a=1&b=2',  // 预览参数 [注意!]这里的`&`字符在命令行中应写成转义字符`\&`

  })

  console.log(previewResult)

})()

当我们使用这个脚本上传完代码就可以在小程序开发助手或者小程序管理平台看到以下内容。

微信管理后台

小程序开发助手页面

最后

我们可以使用 miniprogram-ci 配合 Jenkins 实现自动化部署，提交完成代码就可以自动部署了。以下是一个 github 的 actions 示例。当然也可以使用别的方式，例如本地提交，Jenkins提交等。

name: Feature Branch CI



on:

  workflow_dispatch:

  push:

    branches: ['feature_*']  # 使用通配符匹配所有feature分支



jobs:

  build_and_deploy:

    runs-on: ubuntu-latest

    steps:

      - name: Checkout Repository

        uses: actions/checkout@v3



      - name: Setup Node.js

        uses: actions/setup-node@v3

        with:

          node-version: '20'

          cache: 'yarn'



      - name: Install dependencies

        run: |

          npm install -g miniprogram-ci cross-env

          yarn install --frozen-lockfile



      - name: Build Package

        run: yarn cross-env ENV=PROD uni build -p mp-weixin --mode PROD



      - name: Create private key file

        run: echo "${{ secrets.PRIVATE_KEY }}" > private.key



      - name: Deploy Package

        env:

          APP_ID: ${{ secrets.APP_ID }}

        run: |

          COMMIT_MESSAGE=$(git log --format=%B -n 1 ${{ github.sha }})

          if [[ $COMMIT_MESSAGE =~ VERSION-([A-Za-z0-9_]+-[A-Za-z0-9_-]+)_DEV ]]; then

            VERSION=${BASH_REMATCH[1]}

            echo "Extracted Version: $VERSION"

            miniprogram-ci preview \

              --pp ./dist/build/mp-weixin \

              --pkp ./private.key \

              --appid $APP_ID \

              --uv "${VERSION}" \

              -r 7 \

              --desc "${COMMIT_MESSAGE}" \

              --upload-description "${COMMIT_MESSAGE}" \

              --enable-es6 true \

              --enable-es7 true \

              --enable-minifyJS true \

              --enable-minifyWXML true \

              --enable-minifyWXSS true \

              --enable-minify true \

              --enable-bigPackageSizeSupport true \

              --enable-autoPrefixWXSS true

          else

            echo "No Version found in commit message. Skipping upload."

          fi

金磊 发自 柏林

量子位 | 公众号 QbitAI

最高效的x86芯片，应当是一种怎样的“打开方式”？

就在刚刚，英特尔给出了一份答案——

英特尔® 酷睿™ Ultra 200V系列处理器。

△英特尔高级副总裁Jim Johnson

话不多说，直接上亮点：

• 最快的CPU：E核比上一代快68%，P核则快了14%


• 最快的内置（built-in）GPU：首次推出全新Xe2图形微架构，平均提升30% 的移动图形性能


• 最高AI性能：CPU、NPU和GPU整体算力高达120TOPS，直接拉高AI体验


• 最高效x86：整体功耗降低50%


• 超强的兼容性：各种软件应用程序均可兼容

由此，在搭载英特尔® 酷睿™ Ultra 200V系列芯片之后，AI PC们的生产力也迎来了“蜕变”：

• 每线程处理性能提高3倍


• 峰值性能提高80%


• 续航长达20小时

不仅如此，全球顶级的OEM和ISV们纷纷前来站台，例如谷歌、微软、联想、戴尔、惠普等等。

那么英特尔具体又是如何做到的？以及这个“史上最高效”又是如何界定的？我们继续往下看。

史上最高效的x86处理器

首先我们需要说明的是，Ultra 200V系列一共包含9款处理器，CPU均为8核8线程，GPU和NPU的核心数量会有所不同：

在低功耗方面，这里比较重要的一个变化，就是英特尔对低功耗岛（Low Power Island）做出的改变。

它把Lunar Lake核心数量和缓存增加了一倍（达到4MB和4个内核），并将E核从Crestmont更新到Skymont。

然后英特尔使用各种电源管理技术（包括 Thread Director），通过这个低功耗岛以低功耗来实现效率上的大幅提升。

一个比较有意思的点是，从这里开始，英特尔就直接开始向高通猛开炮火了，性能表现如下：

而除了高通之外，AMD也没能逃过被英特尔拿来公开做比较的命运。

例如在电池寿命方面，英特尔就表示已经超过了AMD和高通。

其次，是CPU方面。

英特尔在CPU上采用了全新的架构，即4个Skymont E核和4个Lion Cove P核，官方所展示的核心信息如下：

不过这里有一个关键的问题。

那就是P核不包括超线程，这个技术实际上允许单个CPU内核支持多个任务线程。

根据英特尔的说法，不采用超线程是因为这样会有助于芯片的整体集成。

尽管英特尔这次是“4+4”模型（8个线程，比上一代少很多），但从给出来的性能结果来看，要比AMD和高通要好得多。

在CPU之后，便是英特尔的内置GPU了。

英特尔这次首次亮相了全新的Xe2图形微架构，不仅适用于集成图形领域，而且适用于独立显卡。

在GPU性能的比较上就更有意思了。

英特尔先是用Ultra 7 155H和Ultra 9 288V在众多游戏上进行了PK，在Xe2加持之下，有了31%的性能提升。

然而到了与高通相比较的时候，结果是这样的：

高通X1E-84-100无法运行23款游戏。

在与AMD HX 370的比较过程中，Ultra 9 288V表现出来的结果是要快出16%。

除此之外，光线追踪也是Xe2的另一大亮点，领先于竞争对手，RT性能提高了30%。

最后，便是Ultra 200V在AI方面的性能了。

正如我们在开头提到的，英特尔此次整体算力达到了120TOPS，其中GPU是67TOPS，NPU 48TOPS，以及还有CPU的5 TOPS。

在性能对比上，同样是和高通相比，在使用Adobe Premiere和Lightroom功能等应用程序时，明显是要快得多。

值得一提的是，在量子位与英特尔交流过程中了解到，英特尔是目前与同行相比，唯一一家在CPU、NPU和GPU三个AI Engine都能做到均衡发展的那一个，而这也成为了其核心竞争力之一。

AI PC们都来站台了

除了英特尔此次“最高效x86处理器”的发布之外，现场的OEM和ISV们也是不可忽视的亮点。

以OEM为例，其数量之多，从一张图就能感受到这个feel了：

近乎所有的AI PC们都有所参与：20多个品牌，80多款机型都搭载了最新的Ultra 200V系列处理器。

不仅如此，在发布活动的现场，谷歌、微软、联想、戴尔和惠普等，也上台表达了对Ultra 200V能上机、上服务而感到的期待。

同样的，即便是在场外，PK的味道依旧是非常浓郁。

例如在demo演示区，英特尔就拉着AMD现场以赛车的游戏来比拼了一番：

**，时长00:17

当然，高通依旧是不能落下：

据了解，首批搭载Ultra 200V处理器的笔记本电脑将在9月24日上线。

不过在此之前，我们也不妨蹲一波更多的实测结果。

One More Thing

英特尔除了Ultra 200V系列芯片之外，此次还发布了Evo Edition标识。

据悉，获得标识的电脑必须通过严苛的英特尔Evo Edition OEM系统验证流程。

每款机型须首先通过预评估，并在通过之后的六个月内接受 10 种不同的测试标准。在此期间会对该机型进行调优，以满足英特尔Evo标准。

我们平时工作中开发APP时，及时为用户提供应用更新是提升用户体验和保证功能完整性的重要一环。本文将通过一段实际的代码示例，详细介绍如何在基于uni-app框架的项目中实现自动检查应用更新的功能，并引导用户完成升级过程。该功能主要涉及与服务器端交互获取最新版本信息、比较版本号、提示用户升级以及处理下载安装流程。

创建一个checkappupdate.js文件

这个文件是写升级逻辑处理的文件，可以不创建，直接在App.vue中写，但是为了便于维护，还是单独放出来比较好，可以放在common或者util目录中（App.vue能引入到就行，随意放，根目录也行）,App.vue中引入该文件，调用升级函数如下图所示：

js完整代码

为了防止一点点代码写，容易让人云里雾里，先放完整代码，稍后再详细解释，其实看注释也就够了。

//这是服务端请求url配置文件,如果你直接卸载下面的请求中，可以不引入

import configService from '@/common/service/config.service.js'



export default function checkappupdate(param = {}) {

	// 合并默认参数

	param = Object.assign({

		title: "A new version has been detected！",

		content: "Please upgrade the app to the latest version！",

		canceltext: "No upgrade",

		oktext: "Upgrade now"

	}, param)



	plus.runtime.getProperty(plus.runtime.appid, (widgetInfo) => {

		let platform = plus.os.name.toLocaleLowerCase() //Android

		let os_version = plus.os.version //13  安卓版本

		let vendor = plus.device.vendor //Xiaomi

		let url = configService.apiUrl

		uni.request({

			url: url + '/checkAppUpdate',

			method: 'GET',

			data: {

				platform: platform,

				os_version: os_version,

				vendor: vendor,

				cur_version: widgetInfo.version

			},

			success(result) {

				console.log(result)

				let versionCode = parseInt(widgetInfo.versionCode)

				let data = result.data ? result.data : null;

				// console.log(data);

				let downAppUrl = data.url

				//判断版本是否需要升级

				if (versionCode >= data.versionCode) {

					return;

				}

				//升级提示

				uni.showModal({

					title: param.title,

					content: data.log ? data.log : param.content,

					showCancel: data.force ? false : true,

					confirmText: param.oktext,

					cancelText: param.canceltext,

					success: res => {

						if (!res.confirm) {

							console.log('Cancel the upgrade');

							// plus.runtime.quit();

							return

						}

						// if (data.shichang === 1) {

						// 	//去应用市场更新

						// 	plus.runtime.openURL(data.shichangurl);

						// 	plus.runtime.restart();

						// } else {

						// 开始下载

						// 创建下载任务

						var dtask = plus.downloader.createDownload(downAppUrl, {

							filename: "_downloads/"

						},

							function (d, status) {

								// 下载完成

								if (status == 200) {

									plus.runtime.install(d.filename, {

										force: true

									}, function () {

										//进行重新启动;

										plus.runtime.restart();

									}, (e) => {

										uni.showToast({

											title: 'install fail:' + JSON

												.stringify(e),

											icon: 'none'

										})

										console.log(JSON.stringify(e))

									});

								} else {

									this.tui.toast("download fail,error code: " +

										status);

								}

							});

						let view = new plus.nativeObj.View("maskView", {

							backgroundColor: "rgba(0,0,0,.6)",

							left: ((plus.screen.resolutionWidth / 2) - 45) +

								"px",

							bottom: "80px",

							width: "90px",

							height: "30px"

						})



						view.drawText('start download...', {}, {

							size: '12px',

							color: '#FFFFFF'

						});

						view.show()

						// console.log(dtask);

						dtask.addEventListener("statechanged", (e) => {

							if (e && e.downloadedSize > 0) {

								let jindu = ((e.downloadedSize / e.totalSize) *

									100).toFixed(2)

								view.reset();

								view.drawText('Progress:' + jindu + '%', {}, {

									size: '12px',

									color: '#FFFFFF'

								});

							}

						}, false);

						dtask.start();

						// }

					},

					fail(e) {

						console.log(e);

						uni.showToast({

							title: 'Request error'

						})

					}

				})

			}

		})



	});

}

函数定义：checkappupdate

定义核心函数checkappupdate，它接受一个可选参数param，用于自定义提示框的文案等信息。函数内部首先通过Object.assign合并默认参数与传入参数，以确保即使未传入特定参数时也能有良好的用户体验。

获取应用信息与环境变量

利用plus.runtime.getProperty获取当前应用的详细信息，包括但不限于应用ID、版本号(version)和版本号代码(versionCode)，以及设备的操作系统名称、版本和厂商信息。这些数据对于后续向服务器请求更新信息至关重要。

请求服务器检查更新

构建包含平台信息、操作系统版本、设备厂商和当前应用版本号的请求参数，发送GET请求至配置好的API地址/checkAppUpdate，查询是否有新版本可用。后端返回参数参考下面：

   /**

     * 检测APP升级

     */

    public function checkAppUpdate()

    {

       $data['versionCode'] = 101;//更新的版本号

       $data['url'] = 'http://xxx/app/xxx.apk';//下载地址

       $data['force'] = true;//是否强制更新

       return json_encode($data);//返回json格式数据到前端

    }

比较版本与用户提示

一旦收到服务器响应，解析数据并比较当前应用的版本号与服务器提供的最新版本号。如果存在新版本，使用uni.showModal弹窗提示用户，展示新版本日志（如果有）及升级选项。此步骤充分考虑了是否强制更新的需求，允许开发者灵活配置确认与取消按钮的文案。

下载与安装新版本

用户同意升级后，代码将执行下载逻辑。通过plus.downloader.createDownload创建下载任务，并监听下载进度，实时更新进度提示。下载完成后，利用plus.runtime.install安装新APK文件，并在安装成功后调用plus.runtime.restart重启应用，确保新版本生效。

用户界面反馈

在下载过程中，通过创建原生覆盖层plus.nativeObj.View展示一个半透明遮罩和下载进度信息，给予用户直观的视觉反馈，增强了交互体验，进度展示稍微有点丑，可以提自己改改哈。

总结

通过上述步骤，我们实现了一个完整的应用自动检查更新流程，不仅能够有效通知用户新版本的存在，还提供了平滑的升级体验。此功能的实现，不仅提升了用户体验，也为产品迭代和功能优化提供了有力支持。开发者可以根据具体需求调整提示文案、下载逻辑、进度样式等细节，以更好地适配自身应用的特点和用户群体。

介绍

数据通常都是持久化在磁盘中的，innodb如果在处理客户端的请求时直接访问磁盘，无论是IO压力还是响应速度都是无法接受的；所以innodb在处理请求时，如果需要某个页的数据就会把整个页都加载到缓存中，数据页会长时间待在缓存中，根据一定策略进行淘汰，后续如果在缓存中的数据就不需要再次加载数据页了，这样即可提高响应时间又可以节省磁盘IO.

buffer pool

上述介绍中我们有提到一个缓存，这个缓存就指的是buffer pool，通过innodb_buffer_pool_size进行设置它的大小，默认为128MB，最小为5MB；可以根据各自线上机器的情况来设置它的大小，设置几个G甚至上百个G都是合理的。

内部组成

buffer pool中包含数据页、索引页、change buffer、自适应hash等内容；数据页、索引页在buffer pool中占用了大部分，不能简单的认为缓冲池中只有数据页和索引页；change buffer在较老的版本中叫insert buffer，后面对其进行了升级形成了现在的change buffer；自适应hash可以方便我们快速查询数据；锁信息、数据字典都是占用比较小的一部分；以上就是buffer pool的内部组成。

页数据

数据页、索引页数据在mysql启动的时候，会直接给申请一块连续的内存空间；如图：

上图中的缓冲页对应的就是磁盘中的数据，默认每个页大小为16KB，并且innodb为每个缓冲页都创建了一些控制块，每个控制块占用大小是800字节左右，需要额外付出百分之5的内存，它记录页所属的表空间编号、页号、缓存页在buffer pool中的地址、链表节点信息等。内存中间可能会有碎片进行对齐。

注意：这里只有缓冲页占用的空间是计算在buffer pool中的。

free链表

根据上面的图可以了解到，buffer pool中有一堆缓冲页，但innodb从磁盘中读取数据页时，由于不能直接知道哪些缓冲页是空闲的、哪些页已经被使用了，导致了不知道把要读取的数据页存放到哪里；此时就引入了一个free链表的概念。如图：

上图中可以看到free链表靠一个free节点连接到控制块中，其中free头节点仅占用40字节空间，但它也不计算在buffer pool中；有了这个free链表后每当需要从磁盘中加载一个页到buffer pool中时就可以从free链表上取一个控制块，把控制块所需信息填充上，同时把从磁盘上加载的数据放到对应的缓冲页上，并把该控制块从free链表中移除。此时就把磁盘中的页加载到内存中了，后续查询数据时就会优先查询该内存页，但每次查询时没办法立刻知道该页是在内存中还是磁盘中，上述操作后还会把这个页信息放到一个散列表中，以（表空间号+页号）作为key，以控制块地址作为value。

flush链表

上述介绍了读数据时通过优先读取内存页可以提高我们的响应速度以及节省磁盘io，那么如果是写数据呢？其实在innodb中，更改也会优先在内存中更改，在后续会根据一定规则（会在后续redolog文章中详细介绍）进行刷盘，在刷盘时只需要刷被更改的缓冲页即可，那么哪些缓存页被更改了innodb是不知道的，此时innodb就设计了flush链表，它和free链表几乎一样，如图：

当需要刷盘时会从flush链表中拿出一部分控制块对应的缓冲页进行刷盘，刷盘后控制块会从flush链表中移除，并放到free链表中。

LRU链表

由于buffer pool的内存区域是有限的，如果当来不及刷盘时内存就不够用了；此时innodb采用了LRU淘汰策略，标准的LRU算法：

• 如果数据页已经被加载到buffer pool中了，则直接把对应的控制块移动到LRU链表的头部；


• 如果数据页不在buffer pool中，则从磁盘中加载到buffer pool中，并把其对应的控制块放到LRU头部；此时内存空间已经满了的话，就会从链表中移除最后一个内存页。

但直接采用lru方案，在内存较小或者临时一次性加载到内存中的页过多时会把真正的热点数据刷掉。如预读和全表扫描。

• 线性预读：如果顺序访问的某个区的页面数超过innodb_read_ahead_threshold（默认值为56）就会触发一次异步预加载下一个区中的全部页到内存中；


• 随机预读：如果某个区的13个连续的页都被加载到young区前1/4的位置中，会触发一次异步预加载本区中的全部页到内存中；


• 全表扫描：把整张表的数据都加载到内存中。

为了解决上述问题，innodb对这个淘汰策略做了一点改变。如图：

innodb根据innodb_old_blocks_pct（默认37）参数把整个lru分成一定比例，具体的淘汰策略：

• 当数据页第一次加载进来时会先放到old head处，当链表满时会把old tail刷盘并从链表中移除。


• 当再次使用一个数据页时，并且该页在old区，会先判断在old区的停留时间是否超过innodb_old_blocks_time（默认1000ms），如果超过则把该数据页移动到young head处，反之移动到old head处。


• 当再次使用一个数据页时，并且该页young区为了节省移动的操作，会判断该缓冲页是否在young区前1/4中，如果在就不进行移动，如果不在则移动到young head处。

多buffer pool实例

对于buffer pool设置很大内存的实例，由于操作各种链表都需要进行加锁这样就比较影响整体的性能，为了提高并发处理能力，可以通过innodb_buffer_pool_instances来设置buffer pool的实例个数。在mysql5.7.5版本中，会以chunk为单位向系统申请内存空间，每个buffer pool中包含了N个chunk。如图：

可以通过innodb_buffer_pool_chunk_size（默认128M）来设置chunk的大小，只能在启动前设置好，启动后可以更改innodb_buffer_pool_size的大小，但必须时innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances的整数倍。

自适应hash

对于b+数来讲，整体的查询时间复杂度为O(logN)，而innodb为了进一步提升性能，引入了自适应hash，对热点数据可以做到O（1）的时间复杂度就可以定位到数据在具体哪个页中。

innodb会自动根据访问频率和模式自动为某些热点页在内存中建立自适应哈希索引，规则：

• 模式：例如有一个联合索引（a,b）;查询条件where a = xxx 与 where a = xxx and b = xxx 这就属于两种模式，如果交叉使用这两种查询，不会为其建立自适应哈希索引；


• 频率：使用一种默认访问的次数大于Math.min(100，页中数据/16)。

根据官方数据，启动自适应哈希索引读写速度可以提升2倍，辅助索引的连接性能可以提升5倍。

总结

通过上述的介绍，希望能帮助大家对buffer pool有一个基础的了解，想进一步深入了解可以通过执行show engine innodb status观察下各种参数，通过对每个参数的细致研究可以全方面的掌握buffer pool。

创作不易，觉得文章写得不错帮忙点个赞吧！如转载请标明出处～

纯手工写一个复选框前端交互，这样可以自由定制自己想要展示的字段和设计风格
写这篇文章主要是抛砖引玉，可能存在槽点，大家多多担待！

1.交互效果展示

用码上掘金在线简单的写了一下:

2.简要说明

$primary-color:#1e80ff; // 主题色-掘金蓝

$primary-disable: #7ab0fd; // 只读或禁用色

可以根据实际需求更改主题色，这里的禁用变量色忘记使用了，sorry！！!

3.布局代码部分

  <!-- page start -->

  <div class="ui-layout-page">

    <h1>请选择关注类型</h1>

    <div class="ui-checkbox">

      <!-- 复选框 item start -->

      <div 

        :class="{'ui-item-box':true,'ui-item-check': i.isCheck,'ui-item-disable':i.disable}" 

        v-for="(i,index) in list" 

        :key="index"

        @click="doCheck(i)">

        <img :src="i.icon"/>

        <span class="span-bar">

          <p class="label-bar">{{i.label}}</p>

          <p class="desc-bar">{{i.desc}}</p>

        </span>

        <!-- 选中标识 start -->

        <span 

          v-if="i.isCheck" 

          class="icon-check">

        </span>

        <!-- 选中标识 end -->

      </div>

      <!-- 复选框 item end -->

    </div>

    <p style="font-size:12px;color:#333">当前选择ids：{{ this.checked.join(',') }}</p>

  </div>

  <!-- page end -->

4.方法和数据结构部分

      checked:['1','2'], 

      list:[

        {

          label:'JYM系统消息',

          id:'1',

          desc:'关注掘金系统消息',

          isCheck:true,

          icon:'https://gd-hbimg.huaban.com/6f3e3ff111c6c98be6785d9eddd5b13f8979ef9d1719e-Xwo8QB_fw658webp', 

          disable:true,

        },{

          label:'JYM后端',

          id:'2',

          isCheck:true,

          desc:'关注后端讨论区新消息',

          icon:'https://gd-hbimg.huaban.com/e2622fe339d655bd17de59fed3b0ae0afb9a16c31db25-YNpnGV_fw658webp', 

          disable:false,

        },{

          label:'JYM前端',

          id:'3',

          isCheck:false,

          desc:'关注前端讨论区新消息',

          icon:'https://gd-hbimg.huaban.com/80765200aa4ffb7683ddea51c3063b0801874fb86324-3OVCQN_fw1200', 

          disable:false,

        },{

          label:'JYM开发工具',

          id:'4',

          isCheck:false,

          desc:'关注开发工具讨论区新消息',

          icon:'https://gd-hbimg.huaban.com/ef1c0e1fb2eae73d674aae791526a331b45b26d2b78e-r4p1aq_fw1200', 

          disable:false,

        }

      ]

      

    /**

     * 复选点击事件 

     * el.disable 禁用状态

     * */ 

    doCheck(el){

      if(el.disable) return   

      if(this.checked.includes(el.id)){ 

        el.isCheck = false

        this.checked=this.checked.filter(item => item !== el.id);

      } else{

        el.isCheck = true

        this.checked.push(el.id)

      }

      this.checked.join(',')

    }

5.样式控制部分

.ui-layout-page{ 

  padding:20px; 

  h1{

    font-size:16px; 

  }



  // 个性化复选框 css start -------------

  .ui-checkbox{

    width:100%;



    $primary-color:#1e80ff; // 主题色-掘金蓝

    $primary-disable: #7ab0fd; // 只读或禁用色



    // 选中状态css

    .ui-item-check{

      border:1px solid $primary-color !important;

      background:rgba($primary-color,0.05) !important;

    }



    // 禁用状态css

    .ui-item-disable{

      border:1px solid #d3d3d3 !important;

      background: #f3f3f3 !important;

      cursor:not-allowed !important;

      .icon-check{

        border-top:20px solid #ccc !important;

      }

      .label-bar{

        color:#777 !important;

      }

      .desc-bar{ 

        color:#a3a3a3 !important;

      }

    }



    // 常规状态css

    .ui-item-box{

      position:relative;

      display:inline-flex;

      align-items: center;

      width:220px;

      height:70px;

      border:1px solid #ccc;

      cursor: pointer; 

      margin:0px 8px 8px 0px;

      border-radius:4px; 

      overflow:hidden;



      &:hover{ 

        border:1px solid $primary-color;

        background:rgba($primary-color,0.05);

      }



      img{

        width:38px;

        height:38px;

        margin-left:15px;

      }

      p{

        margin:0px;

      }

      .span-bar{

        width:0px;

        flex:1 0 auto;

        padding:0px 10px;

        

        .label-bar{

          font-size:14px;

          font-weight:700;  

          margin-bottom:4px;

          color:#333;

        }

        .desc-bar{

          font-size:12px;

          color:#999;

        }

      }

      // 绘制圆角斜三角形

      .icon-check{

        position:absolute;

        width:0px;

        height:0px;

        top:2px;

        right:2px; 

        border-top:20px solid $primary-color;

        border-left:25px solid transparent; 

        border-radius: 5px 3px 5px 0px;

        &:after{

          content:'✓';

          position: relative;

          color:#fff;

          font-size:12px;

          left: -12px;

          top: -26px; 

        }

      }

    }

  }

  // 个性化复选框 css end -------------

}

你有没有想过，仅仅省下1%的计算资源，能为一家大公司带来多大的影响？你可能觉得，1%听起来微不足道，完全不值得一提。但今天我们聊一下一个技术优化点，就是关于如何通过微小的优化，Cloudflare这样的大型网络公司如何省下了大量的计算资源，背后还有不少值得我们学习的智慧。

你也在为计算资源头疼吗？

如果你是个开发者，尤其是负责维护大规模服务的开发者，你一定对计算资源的消耗有深刻的体会。无论是服务器的 CPU 使用率还是内存消耗，甚至是网络带宽，稍有不慎就可能让成本暴增。而且，问题不止是花钱那么简单，资源浪费还会拖慢你的系统，影响用户体验，最终给公司带来巨大的损失。

我要说的是 Cloudfllare 公司的案例，它不是什么宏大的技术革新或颠覆性的变革，而是从一些不起眼的小地方着手，积少成多，最终实现了1%的节省。这背后到底有什么诀窍？我们一起来看看。

1. 换个数据结构，省时又省力

在Cloudflare的案例中，他们的第一个关键优化是引入了更高效的数据结构。在大规模的数据处理中，数据结构的选择往往是决定性能的关键因素。

他们提到了将原有的哈希表结构换成了更适合他们需求的trie（字典树）结构。

下述是然来的 hash 表结构

// PERF: heavy function: 1.7% CPU time

pub fn clear_internal_headers(request_header: &mut RequestHeader) {

    INTERNAL_HEADERS.iter().for_each(|h| {

        request_header.remove_header(h);

    });

}

这是优化之后的版本

pub fn clear_internal_headers(request_header: &mut RequestHeader) {

   let to_remove = request_header

       .headers

       .keys()

       .filter_map(|name| INTERNAL_HEADER_SET.get(name))

       .collect::<Vec<_>>();





   to_remove.int0_iter().for_each(|k| {

       request_header.remove_header(k);

   });

可以看到，他是先构造了一颗 tire 树，然后在进行操作

那么，为什么是trie呢？因为它能更高效地存储和处理特定类型的数据，特别是字符串相关的操作。每次的字符串查找、匹配操作都能变得更加快速，减少了不必要的计算消耗。

这就好比我们平时在超市找商品，如果货架排布得井井有条，一目了然，那么找起东西来肯定又快又省力。

2. 不只是省电，它还能加速系统响应

有时候，节省计算资源并不仅仅体现在电费账单上，它还直接影响系统的响应时间。你有没有遇到过访问一个网站时，页面加载缓慢，让你心急如焚？这很大程度上与后台的计算效率有关。

Cloudflare在优化trie结构后，明显提升了系统的响应速度。

举个通俗的例子，如果原本的哈希表是一个在黑夜中摸索东西的场景，那优化后的trie结构就是在白天找东西——路径明确，操作直观，不浪费多余的时间。这种提升，虽然看起来只是毫秒级的，但在每天处理数以亿计的请求时，省下来的时间就变得非常可观了。

3. 别小看每一次小改动

也许你会问：“这1%的优化，真有那么重要吗？” Cloudflare给出的答案是肯定的。别看只是1%，但在他们这种大规模系统中，每天的请求数以亿计，这1%就意味着节省了大量的服务器计算资源。试想，如果你每天的电费能减少1%，一年下来呢？这可是一笔不小的费用。

而且，从另一个角度看，任何微小的改动都有可能是更大优化的开始。Cloudflare的工程师们通过这次的优化，深入分析了系统中的其他潜在问题，发掘出更多可以提升的地方。这就像是修车时，你发现一个小问题，结果一修就发现了更多的隐患，最后车子不仅恢复了正常，还比以前跑得更快。

4. 现在，从你的小项目开始优化吧

当然，Cloudflare的规模可能让很多普通开发者觉得遥不可及，但这并不意味着我们不能从中学到东西。你手上的小项目同样可以从数据结构、代码效率等方面着手进行优化。

比如，如果你正在处理大量的字符串数据，不妨考虑一下是否可以用trie这种结构来提升效率。或者你可以先从代码的性能分析开始，看看有没有哪个部分的计算特别耗时。通过一点点的优化，哪怕最终只提升了1%，也会让你长期受益。不过，注意，过早优化，依然是万恶之源，先使用优雅的代码实现，上线后做性能瓶颈分析才是正道，换句话说，一个只有 10 几个 PV的地方，那么是再好的数据结构和算法，也很难体现出商业成本上的价值。

5. 未来的路：每一秒都很重要

在如今这个对速度要求极高的互联网时代，每一秒、甚至每一毫秒的节省都至关重要。你以为的“小改动”，可能就是让你的服务脱颖而出的关键。

Cloudflare通过这些小优化，每天节省的计算资源不仅让他们的服务更加高效，也给其他同行树立了一个榜样：技术上的进步不一定是依靠大刀阔斧的改革，有时候，从细微处着手，能带来同样惊人的效果。

不知道，你是否也开始思考自己项目中的那些“隐形”问题了呢？或许，你已经意识到了一些可以优化的地方，但还没来得及动手。那为什么不从今天开始，试着优化一两个小地方呢？也许下次的1%提升，就来自于你的一点点努力。

这个世界上没有小优化，只有还没被发现的优化。

梦晨 发自 凹非寺

量子位 | 公众号 QbitAI

华为三折叠新品发布会，弹幕一片的 “报价吧，让我死心” 。

全球首款三折叠手机MateXT，价格正式揭晓：

• 256GB版，19999元


• 512GB版，21999元


• 1TB版，23999元

预计9月20日上午10点08分正式开售，发布会与苹果同一天，正式开卖也与苹果同一天。

看到这里，你是死心了还是动心了？

华为MateXT系列是全球最大折叠屏手机，全展开总计10.2英寸屏幕。

同时，它还是全球最薄折叠屏手机，三屏展开状态只有3.6mm。

余承东手持样机在现场表示，“把平板装在口袋里”，这个梦想已经实现了。

作为对比华为平板在售型号最小尺寸为11英寸。

不过也有许多网友表示： “它和平板的区别在于平板我买得起”。

配合官方配件折叠触控键盘，把电脑装在口袋里也实现了。

余承东表示这是一款“大家都能想得到，但是做不出来的产品”。

这样一款全新形态的手机，究竟有哪些使用场景？

发布会现场也做了演示。

三折叠屏都能怎么用

面向商务人士，出差路上也要办公，是华为MateXT这次主打的场景之一。

单屏折叠，扫码登机便于持握。

双屏展开，适合在线浏览简单资讯。

三屏全展开，连复杂的行业报告都能拿捏。

放在一起对比，余承东称三屏模式的实际可视内容在双屏的两倍以上。

除了严肃的工作场景，三屏展开来看电影视觉效果也更震撼。

三折叠除了常规横向使用，华为也考虑到了竖起来使用这种需求，官方支架配件也支持90度旋转。

竖屏短视频刷起来也更带感了。

对于APP的适配方面，余承东开了个玩笑： “小红书秒变大红书” 。

再接下来还演示了华为系统搭载的一些AI功能。

比如AI总结，可以实现左边原文，右边摘要，无需来回切换。

AI翻译同理，方便跳转回原文。

AI修图能力虽然和三折叠屏没太多联动关系，而且很多人已经上手体验过。

但鉴于前面有几款手机并未召开发布会，华为官方在新机发布会上讲解还是第一次。

三折叠手机还有哪些亮点？

看过三折叠屏都有哪些玩法之后，是时候再了解一下背后的技术突破了。

这是折叠屏铰链系统同时实现内外弯折。

也是超薄大屏第一次实现内外弯折。

余承东讲解“Z”字形内外弯折最大的难点在于，会出现两种互斥的力。

这一次能实现，背后最大助力也在现场揭秘：华为首创的天工铰链系统，实现双轨联动。

具体细节并未透露太多，目前已知采用多向弯折柔性材料，外折部分抗拉伸，内折部分抗挤压。

与之配合，屏幕本身也有特别设计，内侧是业界最大的UTG玻璃，最外层为非牛顿流体材料，双层都有不错的抗冲击能力。

还记得整部手机只有3.6mm厚度么，刨去前后外壳、屏幕、电路板等，留给电池的空间只剩……

1.9mm！

最后，华为高端手机向来重视的影像系统、通信能力这次依然保持高水准。

华为首款三折叠手机，满足你的期待了吗？

需求

我们今天来实现一下,点击当前用户的div, 自动滚动到用户在排行榜中的位置.

效果

大家可以先看一下下面的GIF, 所实现的效果.

实现

1. 准备DOM 结构

首先,我们在进行列表建设的时候, 需要准备好一个数据. 因为此处我们是使用的vue3来进行编写. 对于列表我们使用的是v-for列表渲染来做的. 在渲染的时候, 我们需要给每一个列表项(当前就是每一个用户项)添加一个自定义属性. 具体的话, 可以看下 下方的关键代码.

核心代码就是

 <div v-for="(item, index) in rankingData" :key="item.user.id" :data-key="item.user.id"

 </div>

因为数据是后端返回的, 是包含的user_id,而且这个user_id 是不可能重复的. 我们只要保证每个列表的自定义的属性是唯一的即可.

2. 绑定方法,实现方法

接下来,我们需要考虑的是,在点击的时候,如何获取到当前的dom. 这对我们目前来说就很容易了, 因为我们可以根据据user_id 拿到我们当前点击的dom.

添加一个方法

<!-- 当前用户排名情况 -->

        <div class="text-white w-[100%] ...."  @click="scrollToCurrentRankingPosition(userId)">

实现方法.

第一步: 拿到rankingList的dom实例.

这里我们通过vue3提供ref拿到dom. 可以看下
模板引用

<div v-else class=" overflow-auto bg-white" ref="rankingList">



const rankingList = ref(null);

第二步: 根据userId获取到具体的DOM

const currentItem = rankingList.value.querySelector(`[data-key="${id}"]`);

第三步: 使用scrollIntoView方法滚动视图到当前选中的元素

 // 平滑滚动到当前元素

  currentItem.scrollIntoView({ behavior: 'smooth', block: 'center' });

scrollIntoView方法 讲解:

• Element 接口的 scrollIntoView() 方法会滚动元素的父容器，使被调用 scrollIntoView() 的元素对用户可见。

简单来讲就是被调用的者的元素出现在用户的视线里面.
scrollIntoView() 方法有三种调用形式：

参数

• alignToTop（可选）：布尔值，控制元素滚动到顶部还是底部对齐。默认为 true（顶部对齐）。


• scrollIntoViewOptions（可选实验性）：对象，包含以下属性：
  
  
  
  
  • behavior：定义滚动行为是平滑动画还是立即发生。可取值有 smooth（平滑动画）、instant（立即发生）或 auto（由CSS的 scroll-behavior 属性决定）。
  
  
  • block：定义垂直方向的对齐方式，可取值有 start、center、end 或 nearest。默认为 start。
  
  
  • inline：定义水平方向的对齐方式，可取值有 start、center、end 或 nearest。默认为 nearest。
  
  
  
  

目前我们实现了效果.

但是我们发现,还可以继续改进, 目前我们虽然滚动到了屏幕的中间, 但是我们很难去发现. 所以我们可以继续完善一下这个方法. 就是滚动到视图的中间的同时高亮选中的DOM.

3. 额外扩展, 高亮当前的元素

定义一个两个方法,一个用于应用样式, 一个应用于移除样式.

const applyHighlightStyles = (element) => {

    element.style.transition = 'background-color 1s ease, border-color 1s ease';

    element.style.border = '1px solid transparent'; // 预定义边框样式

    element.style.borderColor = '#006cfe'; // 设置边框颜色

    element.style.backgroundColor = '#cfe5ff'; // 设置背景色为浅蓝色

};



const removeHighlightStyles = (element) => {

    element.style.backgroundColor = ''; // 移除背景色

    element.style.borderColor = 'transparent'; // 移除边框颜色

};

然后再在我们之前的方法的后面加入代码

            // 设置高亮显示的样式

            applyHighlightStyles(currentItem);



            // 清除之前的定时器（如果有）

            if (currentItem._highlightTimer) {

                clearTimeout(currentItem._highlightTimer);

            }



            // 设置定时器，2秒后移除高亮显示

            currentItem._highlightTimer = setTimeout(() => {

                removeHighlightStyles(currentItem);

                currentItem._highlightTimer = null;

            }, 2000);

然后在组件卸载前记得清除定时器.

onUnmounted(() => {

    if (rankingList.value) {

        // 遍历所有项目，清除定时器

        rankingList.value.querySelectorAll('[data-key]').forEach(item => {

            if (item._highlightTimer) {

                clearTimeout(item._highlightTimer);

                item._highlightTimer = null;

            }

        });

    }

});

效果:

总结

整体下来的思路就是: