想要直接下载这款神器？没时间看正文章节？没问题！查看下载方式

为什么需要透明度工具？

想象一下，在你做一件事情时，桌面上堆满了各种窗口，屏幕一片杂乱无章。或许你正在使用数位板画画，想对着指定的图片描画练习。那么，这个工具就能帮你完美解决这个烦恼——通过透明化某些窗口，让它们悄无声息地存在，但又不完全消失，既方便操作，又不影响桌面整洁。

这款工具有啥亮点？

快捷键随心调节透明度

• 降低透明度：按 Ctrl + Alt + Up，让窗口变得更加透明。
• 增加透明度：按 Ctrl + Alt + Down，让窗口变得更不透明。
• 恢复默认透明度：按 Ctrl + Alt + 0，恢复窗口的默认透明度。

系统托盘图标，安静待命

程序启动后，它会默默缩到系统托盘，图标看不见，想偷懒就偷懒。你只需要右键点击托盘图标选择“退出”或者快捷键【ctrl + alt + esc】即可，不会打扰你正在做的事情。

打包为 EXE，随时随地使用

不想麻烦安装 Python 环境？没问题！这个工具可以直接打包为一个 EXE 文件，免安装，随时随地运行。

如何下载并使用这个工具？

下载方式

1. 访问 GitHub 仓库，安装python 环境自行编译 EXE 文件, 根据readme文件调试修改源码。
2. 如果没有 Python 环境，也可以直接下载 EXE 最新版本运行(推荐，下载就用)。

调试学习

安装依赖（如果需要）

如果你选择源码版本， 请阅读git仓库内的readme文件

使用方法

1. 运行 main.py 文件（或下载 EXE 文件直接运行）。
2. 使用快捷键调节窗口透明度，或通过托盘图标退出程序。

总结

这款 Windows 窗口透明度工具 是一款非常实用的桌面工具，尤其适合那些希望提升工作效率、保持桌面整洁的朋友。通过简单的快捷键或托盘操作，你就能轻松调整窗口透明度，无论是工作还是摸鱼，都能得到很好的体验。如果你也想在桌面上“隐形”一些窗口，就快来试试这款工具！

作者 王宁
联系邮箱：wxs_code@126.com

在Java生态中，中间件是构建分布式系统的基石。本文将对常用中间件进行横向对比，分析其核心差异与适用场景，方便找到最适合业务的解决方案。

消息队列中间件

1. Kafka

Kafka以其高吞吐量和持久化能力著称，特别适合大数据日志采集和流处理场景。它的多副本机制确保了数据的高可靠性，但消息延迟较高，通常在毫秒级别。对于需要实时性极高的场景（如金融交易），Kafka可能不是最佳选择。Kafka的扩展性很强，但功能扩展依赖社区插件，可能需要额外的开发成本。

短评：搞大数据？没得选，Kafka就是你的菜。不过，准备好熬夜调优吧，这货可不是省油的灯。

• 官网地址: https://kafka.apache.org/
• 文档地址: https://kafka.apache.org/documentation/

2. RocketMQ

RocketMQ在低延迟和事务消息支持上表现优异，特别适合金融、电商等需要高可靠性和顺序消息的场景。它的毫秒级延迟和事务消息机制是其核心竞争力。不过，RocketMQ的社区生态相对较弱，且运维复杂度较高，适合有一定技术储备的团队。

短评：低延迟、事务消息，金融场景的神器。不过，社区生态弱了点，出了问题得自己扛。

• 官网地址: https://rocketmq.apache.org/
• 文档地址: https://rocketmq.apache.org/docs/

3. RabbitMQ

RabbitMQ作为老牌消息队列，以其灵活的路由机制和友好的管理界面著称，特别适合企业级系统集成。它支持完整的AMQP协议，但在单机吞吐量上表现较弱，通常只能达到万级TPS。对于需要高吞吐量的场景，RabbitMQ可能不是最佳选择。

短评：适合中小企业，功能齐全，但别指望它能扛住双十一的流量。

• 官网地址: https://www.rabbitmq.com/
• 文档地址: https://www.rabbitmq.com/documentation.html

总结: Kafka适合大数据场景，RocketMQ适合金融交易等低延迟场景，而RabbitMQ则更适合企业级系统集成。选择时需根据业务需求和团队技术栈进行权衡。

缓存中间件

1. Redis

Redis是缓存中间件的事实标准，支持丰富的数据结构（如字符串、哈希、列表等），并且单线程模型保证了操作的原子性。它的集群方案成熟（如Codis和Redis Cluster），适合高并发场景。不过，Redis的内存成本较高，且持久化可能影响性能，需要根据业务场景合理配置。

短评：缓存界的万金油，啥场景都能上。不过，内存贵啊，老板心疼(还好不是我们2333)。

• 官网地址: https://redis.io/
• 文档地址: https://redis.io/documentation

2. Memcached

Memcached是一个高性能的分布式内存缓存系统，特别适合缓存简单的键值对数据。它的设计简单，性能极高，适合读多写少的场景。不过，Memcached不支持持久化和复杂的数据结构，且集群功能较弱，适合小型项目或临时缓存需求。

短评：简单粗暴，适合临时缓存需求。不过，功能太单一，别指望它能干复杂的活儿。

• 官网地址: https://memcached.org/
• 文档地址: https://github.com/memcached/memcached/wiki

3. Ehcache

Ehcache是一个纯Java的缓存框架，集成简单，适合单机或小型分布式系统。它支持本地缓存和分布式缓存，且与Spring等框架集成良好。不过，Ehcache的分布式缓存功能较弱，且在大规模集群下性能表现不如Redis。

短评：单机缓存的好选择，但分布式场景就别指望它了。

• 官网地址: https://www.ehcache.org/
• 文档地址: https://www.ehcache.org/documentation/

4. Caffeine

Caffeine是一个基于Java 8的高性能本地缓存库，设计目标是替代Guava Cache。它的性能极高，支持异步加载和过期策略，适合高并发本地缓存场景。不过，Caffeine仅支持本地缓存，无法用于分布式系统。

短评：本地缓存的神器，性能杠杠的。不过，分布式场景就别想了。

• 官网地址: https://github.com/ben-manes/caffeine
• 文档地址: https://github.com/ben-manes/caffeine/wiki

5. Hazelcast

Hazelcast是一个分布式内存数据网格，支持缓存、分布式计算和消息队列等功能。它的分布式缓存功能强大，且支持自动分片和数据备份，适合大规模分布式系统。不过，Hazelcast的配置和运维较为复杂，且内存占用较高。

短评：功能强大，但运维是个坑，适合有经验的团队。

• 官网地址: https://hazelcast.com/
• 文档地址: https://docs.hazelcast.com/hazelcast/latest/

6. Ignite

Apache Ignite是一个分布式内存计算平台，支持缓存、SQL查询和机器学习等功能。它的功能非常丰富，适合需要复杂数据处理和计算的场景。不过，Ignite的学习曲线较陡峭，且对硬件资源要求较高。

短评：功能强大，但学习成本高，适合技术储备足的团队。

• 官网地址: https://ignite.apache.org/
• 文档地址: https://ignite.apache.org/docs/latest/

总结:

• Redis: 大多数场景的首选，支持丰富数据结构和高并发。
• Memcached: 适合简单的键值对缓存，性能极高但功能单一。
• Ehcache: 适合单机或小型分布式系统，集成简单但分布式功能较弱。
• Caffeine: 本地缓存的最佳选择，性能优异但不支持分布式。
• Hazelcast: 适合大规模分布式系统，功能强大但运维复杂。
• Ignite: 适合复杂数据处理和计算场景，功能丰富但学习成本高。

选择缓存中间件时，需根据业务需求、团队技术栈和运维能力进行权衡。对于大多数Java项目，Redis和Caffeine是优先考虑的选择。

数据库中间件

1. ShardingSphere

ShardingSphere是一个功能强大的分库分表中间件，支持多种分片策略，并且兼容MySQL协议。它的SQL改写能力非常完善，适合复杂的分布式数据库场景。不过，分布式事务的实现较为复杂，且跨库Join的效率较低，需要根据业务场景进行优化。

短评：分库分表的神器，功能强大，但调优得花点时间。

• 官网地址: https://shardingsphere.apache.org/
• 文档地址: https://shardingsphere.apache.org/document/current/

2. MyCat

MyCat是一个轻量级的数据库中间件，配置简单，适合快速上手。它支持读写分离，但在复杂查询场景下性能较差，且社区活跃度逐渐下降，适合小型项目或存量系统的维护。

短评：适合小型项目，但别指望它能扛住大流量。

• 官网地址: http://www.mycat.org.cn/
• 文档地址: http://www.mycat.org.cn/document/

总结: 新项目推荐使用ShardingSphere，其功能强大且扩展性好；对于小型项目或存量系统，MyCat是一个轻量级的选择。

RPC框架

1. Dubbo

Dubbo是Java生态中最成熟的RPC框架之一，服务治理能力非常完善，特别适合微服务架构。它的中文文档丰富，支持多种协议（如Dubbo协议、HTTP等），但配置较为复杂，且生态碎片化问题较为明显。

短评：微服务的神器，功能齐全，但配置得花点时间。

• 官网地址: https://dubbo.apache.org/
• 文档地址: https://dubbo.apache.org/zh/docs/

2. gRPC

gRPC是一个跨语言的RPC框架，基于HTTP/2协议，性能优异。它使用Protobuf作为序列化工具，适合跨语言服务调用场景。不过，gRPC的服务治理功能较弱，需要二次开发，且调试成本较高。

短评：跨语言的神器，性能炸裂，但调试得花点心思。

• 官网地址: https://grpc.io/
• 文档地址: https://grpc.io/docs/

总结: 对于Java微服务架构，Dubbo是首选；如果需要跨语言支持，gRPC是更好的选择。

注册中心

1. Nacos

Nacos是一个功能强大的注册中心，同时支持服务发现和配置管理。它的可视化控制台非常友好，且支持CP/AP模式切换，适合大多数微服务场景。不过，在大规模集群下，Nacos的性能可能会有所衰减。

短评：微服务的神器，功能强大，配置简单。

• 官网地址: https://nacos.io/
• 文档地址: https://nacos.io/zh-cn/docs/what-is-nacos.html

2. Zookeeper

Zookeeper是一个老牌的分布式协调服务，强一致性是其核心优势，适合需要高可靠性的场景。不过，Zookeeper的写性能较差，且运维复杂度较高，适合有经验的团队。

短评：功能强大，但运维麻烦，适合有经验的团队。

• 官网地址: https://zookeeper.apache.org/
• 文档地址: https://zookeeper.apache.org/doc/

总结: 对于大多数微服务场景，Nacos是更好的选择；如果需要强一致性，Zookeeper仍然是一个可靠的选择。

配置中心

Apollo

Apollo是一个功能强大的配置中心，支持配置的灰度发布和版本追溯，特别适合中大型企业。它的多环境支持能力非常强大，但部署架构较重，学习曲线较陡峭。

短评：配置中心的神器，功能强大，但部署麻烦。

• 官网地址: https://www.apolloconfig.com/
• 文档地址: https://www.apolloconfig.com/#/zh/README

总结: Apollo适合中大型企业，对于轻量级场景，可以考虑使用Nacos的配置管理功能。

分布式事务

Seata

Seata是一个开源的分布式事务解决方案，支持AT和TCC模式，适合需要强一致性的业务场景。它的开源社区活跃，且与Spring Cloud集成良好，但性能损耗较明显，且对业务代码有一定的侵入性。

短评：分布式事务的神器，功能强大，但性能损耗明显。

• 官网地址: https://seata.io/
• 文档地址: https://seata.io/zh-cn/docs/overview/what-is-seata.html

总结: 对于金融级场景，推荐使用TCC模式；对于常规业务，AT模式可以降低开发成本。

综合选型建议

1. 消息队列：优先考虑RocketMQ，平衡吞吐量与功能完整性。
2. 缓存：Redis仍是首选，注意合理设计过期策略。
3. 微服务架构：Dubbo + Nacos组合拳。
4. 分布式事务：非核心业务可暂缓引入，必须使用时推荐Seata AT模式。

技术选型没有银弹，得根据业务需求和团队技术栈来定。不过，记住一点：别为了技术而技术，解决问题才是王道。祝大家少踩坑，多摸鱼！😄

这两天自己写onesite 的时候遇到一个小问题。原框架使用video.js来播放视频，在网络环境下可以正常播放视频，且可以拖动或点击进度条能正常跳转。但是使用koa-static代理的本地视频文件则无法使用进度条，一旦修改进度，那么就会重头开始播放。

整理了一个现象的表格如下：

原因

这么一看就清晰了，应该是谷歌浏览器或者使用本地静态资源托管的时候出错了。先搜一下别人有没有遇到过吧。不出所料，打开bing，输入关键词，回车。 稍微看了一下搜索结果，主要原因是：koa-static返回了一个文件流，并且没有设置response的header配置，谷歌浏览器不知道总文件的大小，它就每次都重头开始播放。火狐没问题，可能他们考虑到了这种情况，做了兼容。

解决

知道了问题就好解决了，在托管资源文件的时候，添加header配置就行。 我这里使用的后端是koa + koa-static + koa-mount 。koa-static用来托管文件，koa-mount同来为静态文件添加统一的前缀。完整的代码配置如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

const Koa = require('koa'); 
const static = require('koa-static')
const Mount = require('koa-mount');

const app = new Koa();

app.use(Mount("/video/",static(CONFIG.VISIT_PATH, {
  prefix: "/video",
  index: false,     // 默认为true  访问的文件为index.html  可以修改为别的文件名或者false
  hidden: true,     // 是否同意传输隐藏文件
  defer: true,      // 如果为true，则在返回next()之后进行服务，从而允许后续中间件先进行响应
  setHeaders: (ctx, filepath, stat)=>{ // stat:包含文件的信息
    ctx.setHeader('Content-Type', 'video/mp4'); // 设置Content-Type
    ctx.setHeader('Content-Length', stat.size); // 设置Content-Length
    ctx.setHeader("Accept-Ranges", "bytes");    
  }
})))

const SERVER_PORT = 80
app.listen(SERVER_PORT, () => { 
  console.log("Start App From koa");
});

其实不论你用的啥后端框架，主要思想就是设置响应头，照着上面的内容设置就可以了。

1. 创建Github仓库

首先，在Github上创建两个仓库，分别用于存放博客源文件和生成的静态资源。

• 博客源文件仓库：用于存放博客的源文件，例如：hexo-blog。
  这个仓库可以设置为私有的，防止_config.yml文件中某些隐私设置泄露。待会还需要再这个仓库中设置秘密变量和工作流。
• 静态资源仓库：用于存放生成的静态资源，格式为：Github用户名.github.io。 例如：我的就是 xswangcode.github.io。
  1. 注意：静态资源仓库的名称必须是 Github用户名.github.io，否则无法使用Github Action的部署功能。
  2. 两个仓库的主分支都为 main。

2. 配置工作流

Github Action 官方文档

2.1 创建工作流文件

在博客源文件仓库[hexo-blog]中，创建一个 .github/workflows/deploy.yml文件，内容如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

name: Build and Deploy View 

on:
  workflow_dispatch:
  push:
    branches:
      - main 

  schedule:
    - cron: '0 4,16 * * *' # 每天12点和24点自动执行
    
permissions: read-all

jobs:
  build:
    runs-on: ubuntu-20.04
    permissions:
      contents: read
  
    steps:
    - name: Checkout repository
      uses: actions/checkout@v2
      with:
        ref: main
        repository: xswangcode/hexo-blog
        timezoneLinux: "Asia/Shanghai"


    - name: Set up Node.js
      uses: actions/setup-node@v1
      with:
        node-version: 20

    - name: Cache node_modules 
      uses: actions/cache@v2 
      env:
        cache-name: cache-node-modules
      with:
        path: ~/.npm
        key: ${{ runner.os }}-build-${{ env.cache-name }}-${{ hashFiles('**/package-lock.json') }}
        restore-keys: |
          ${{ runner.os }}-build-${{ env.cache-name }}-
          ${{ runner.os }}-build-
          ${{ runner.os }}- 

  
    - name: Install dependencies
      run: npm i  package.json -g 
    
    - name: Install Hexo-cli # 安装 Hexo
      run: |
        npm install hexo-deployer-git 
        npm install  hexo-cli -g
        echo "install hexo successful"
      
    - name: Build Blog
      run: |
        hexo clean
        hexo g
        echo "build blog successful"

    - name: Deploy DoubleAm's Blog # 设置 git 信息并推送静态博客文件
      env:
        GIT_NAME:  xswangcode
        GIT_EMAIL: ${{ secrets.GH_EMAIL }}
        GH_TOKEN:  ${{ secrets.GH_TOKEN }}
      run: |
          git config --global user.name "$GIT_NAME"
          git config --global user.email "$GIT_EMAIL"
          sed -i -e "s/https:\/\/github.com/https:\/\/${{ env.GH_TOKEN }}@github.com/g" _config.yml
          hexo deploy
      
    - run: |
        echo "Deploy Successful!"
        echo "Visit website: https://xswangcode.github.io !"
        echo "Visit website: https://xswang.pages.dev     !"

上边的很多配置也参考了其他人的配置，感谢各位大佬的分享。

2.2 修改工作流内容

下面说下要改的位置

1. 25行：repository: xswangcode/hexo-blog 替换成你自己的仓库地址，如果你按照上面的步骤做的话，就把用户名改成你自己的就行。
2. 64行：这里是配置git用户，需要把用户名改成你自己的。
3. 75行：同上，这一行是输出最后网站的路径。这个不影响最终部署，但是会显示在 github action 的日志中。

• 如果觉得太麻烦，也提供一个最简单的方案：在编辑器中打开deploy.yml 文件，搜索 xswangcode,全部替换成你自己的名字就够了，也可以正常执行。

2.3 准备Github Token

可以看到我在65行和70行都是在配置Github Token，这个Token是用来在部署时，让Github Action 能够提交代码到你的仓库的。
先要创建一个Token，在Github的设置中，找到 Developer settings，然后找到 Personal access tokens，点击 Generate new token，然后输入一个Token的名称，选择 repo 和 workflow 权限，然后点击 Generate token，生成一个Token，这个Token只会显示一次，所以要保存好。

2.4 配置Github Secrets

在Github的仓库中，找到 Settings，然后找到 Secrets，，点击 New repository secret，然后输入一个名称，这里我输入的是 GH_TOKEN，然后把之前生成的Token粘贴到 Value中，点击 Add secret，这样就配置好了。
然后按照相同的步骤添加GH_EMAIL变量。

2.5 检查hexo 配置

如果你的hexo博客的所有配置已经修改完成了，并且也在根目录的_config.yml配置了deploy相关内容，如下。

1
2
3
4
5

deploy:
  type: git
  repo: https://github.com/xswangcode/xswangcode.github.io.git  # 这里改成你自己的仓库地址！
  branch: main
  message:  "🎉update by Github Action💯 - {{ now('yyyy-MM-dd hh:mm:ss') }}" 

2.6 设置Github Pages

在静态资源的 xswangcode.github.io仓库中，找到 Settings，然后找到 Pages，然后把 Source 设置为 main branch / root ，然后点击 Save。 设置完成后如下：

2.7 见证奇迹的时刻

在hexo-blog 目录下，执行

1

hexo new test

然后执行然后把新增加的文件提交并推送到Github仓库。静等1分钟左右，进去https://{你的用户名}.github.io/ 看看吧。

Quick Start

Create a new post

1

$ hexo new "My New Post"

More info: Writing

Run server

1

$ hexo server

More info: Server

Generate static files

1

$ hexo generate

More info: Generating

Deploy to remote sites

1

$ hexo deploy

More info: Deployment