如何让你喜欢的原神角色陪你写代码

每天上班，脑子里面就想着一件事，原神，啊不对，VsCode！启动！(doge 狗头保命)，那么如何将这两件事情结合起来呢？特别是原神里面有那么多我喜欢的角色。

最终效果预览

• 右下角固定一只小可爱
  
  
  
  
  • 
  
  
  
  


• 全屏一只小可爱
  
  
  
  
  • 
  
  
  
  

省流直接抄作业版

{

  "background.customImages": [

    "https://upload-bbs.miyoushe.com/upload/2023/02/24/196231062/8540249f2c0dd72f34c8236925ef45bc_3880538836005347690.png",

    "https://user-images.githubusercontent.com/41776735/163673800-0e575aa3-afab-405b-a833-212474a51adc.png"

  ],

  "background.enabled": true,

  "background.style": {

    "content": "''",

    "width": "30%",

    "height": "30%",

    "opacity": 0.3,

    "position": "absolute",

    "bottom": "0",

    "right": "7%",

    "z-index": "99999",

    "background-repeat": "no-repeat",

    "background-size": "contain",

    "pointer-events": "none"

  },

  "background.useDefault": false,

  "background.useFront": true

}

2.2 全屏图片配置

{

  "background.customImages": ["https://upload-bbs.miyoushe.com/upload/2024/01/15/196231062/1145c3a2f56b2f789a9be086b546305d_3972870625465222006.png"],

  "background.enabled": true,

  "background.style": {

    "content": "''",

    "pointer-events": "none",

    "position": "absolute",

    "z-index": "99999",

    "height": "100%",

    "width": "100%",

    "background-repeat": "no-repeat",

    "background-size": "cover",

    "background-position": "content",

    "opacity": 0.3

  },

  "background.useDefault": false,

  "background.useFront": true

}

详细说明版

第一步，你还是需要下载 background 这个插件。

• background 插件的官方中文文档

第二步，配置解析

我们看官方文档里面，有两个配置是需要说明一下的

• background.customImages:
  
  
  
  
  • 是一个数组，默认是用第一张图片做背景图，在分屏的时候第二屏就用的是数组的第二个元素，以此类推
  
  
  • 支持 https 协议和本地的 file 协议
    
    
    
    • 因为我有公司机器和自己电脑，所以本地协议不太适用我，但是我之前一直用的是本地协议，并且下面会教大家如何白嫖图床
    
    
    
    
  
  
  
  


• background.style:
  
  
  
  
  • 作为一个前端，看到上面的内容是不是十分的熟悉，其实这个插件的底层原理就是去改 vscode 的 css，所以你可以想想成一个需求，在一个界面上显示一张图片，css 可以怎么写，背景图就可以是啥样的
  
  
  • 如果你看不懂 css 代码，你可以直接复制我上面提供的两种配置，一个全屏的，一个是在右下角固定一小只的
  
  
  
  


• 如果你觉得背景图太亮了，有点看不清代码，你可以修改 background.style.opacity这个属性，降低图片的透明度。


• 发现最新版本支持 background.interval 来轮播背景图了

高清社死图片

OK，其实到这就没啥了，但是到这里和原神好像并没有什么太大的关系，那现在我就教你怎么白嫖米游社的图床，并且获取高清的原神图片

• 第一步，你需要有一个米游社的账号，当然，玩原神的不能没有吧


• 第二步，随便找个帖子进行评论回复，如果你怕麻烦别人，可以自己发一贴
  
  
  
  
  • 
  
  
  
  


• 第三步：新标签页打开
  
  
  
  
  • 
  
  
  
  


• 到这里，你就能白嫖米游社的图床了，如果你是评论的自己的图片，新标签页打开之后，删除 url 中 ? 后面所有的内容，就可以得到原图 https 的链接了


• 但是又遇到一个问题，我就是很喜欢米游社的图片，但是图片的分辨率太低了怎么办？
  
  
  
  
  • 提供两个用 ai 来放大图片的网站
  
  
  • waifu2x.udp.jp/
  
  
  • bigjpg.com/
  
  
  • 把图片放大之后，在用上面白嫖图床的方法就可以了
  
  
  
  

最后

水一期，求三连 + 可以在评论区分享你的背景图嘛

抛个砖头

不知道大家用了这么久的掘金，有没有对它文章中的阅读量的实现有过好奇呢？

想象一下，你每次打开一篇文章时，都会有一个数字告诉你多少人已经读过这篇文章。那么这个数字是怎么得出来的呢？

有些人可能会认为，每次有人打开文章，数字就加1，不是很简单吗？ 起初我也以为这样，哈哈（和大家站在同一个高度），但（好了，我不说了，继续往下看吧！）

引个玉

文章阅读量的统计看似简单，实则蕴含着巧妙的逻辑和高效的技术实现。我们想要得到的阅读量，并非简单的页面刷新次数，而是真正独立阅读过文章的人数。因此，传统的每次页面刷新加1的方法显然不够准确，它忽略了用户的重复访问。

同时，阅读作为一个高频操作，如果每次都直接写入数据库，无疑会给数据库带来巨大的压力，甚至可能影响到整个系统的性能和稳定性。这就需要我们寻找一种既能准确统计阅读量，又能减轻数据库压力的方法。

Redis，这个高性能的内存数据库，为我们提供了解决方案。我们可以利用Redis的键值对存储特性，将用户ID和文章ID的组合作为键，设置一个短暂的过期时间，比如15分钟。当用户首次访问文章时，我们在Redis中为这个键设置一个值，表示该用户已经阅读过这篇文章。如果用户在15分钟内再次访问，我们可以直接判断该键是否存在，如果存在，则不再增加阅读量，否则进行增加。

这种方法的优点在于，它能够准确地统计出真正阅读过文章的人数，而不是简单的页面刷新次数。同时，通过将阅读量先存储在Redis中，我们避免了频繁地写入数据库，从而大大减轻了数据库的压力。

最后，我们还需要考虑如何将Redis中的阅读量最终写入数据库。由于数据库的写入操作相对较重，我们不宜频繁进行。因此，我们可以选择在业务低峰期，比如凌晨2到4点，使用定时任务将Redis中的阅读量批量写入数据库。这样，既保证了阅读量的准确统计，又避免了频繁的数据库写入操作，实现了高效的系统运行。

思路梳理

代码层面

项目使用的后端框架为NestJS

配置下redis

一、安装redis plugin

npm install --save redis

二、创建redis模块

三、初始化连接redis相关配置

@Module({

  providers: [

    RedisService,

    {

      provide: 'REDIS_CLIENT',

      async useFactory(configService: ConfigService) {

        console.log(configService.get('redis_server_host'));

        const client = createClient({

          socket: {

            host: configService.get('redis_server_host'),

            port: configService.get('redis_server_port'),

          },

          database: configService.get('redis_server_db'),

        });

        await client.connect();

        return client;

      },

      inject: [ConfigService],

    },

  ],

  exports: [RedisService],

})

Redis是一个Key-Value型数据库，可以用作数据库，所有的数据以Key-Value的形式存在服务器的内存中，其中Value可以是多种数据结构，如字符串（String）、哈希（hashes）、列表（list）、集合（sets）和有序集合（sorted sets）等类型

在这里会用到字符串和哈希两种。

创建文章表和用户表

我的项目中创建有post.entity和user.entity这两个实体表，并为post文章表添加以下

这三个字段，在这里我们只拿 阅读量 说事。

访问文章详情接口-阅读量+1

  /**

   * @description 增加阅读量

   * @param id

   * @returns

   */

  @Get('xxx/:id')

  @RequireLogin()

  async frontIncreViews(@Param('id') id: string, @Req() _req: any,) {

    console.log('frontFindOne');

    return await this.postService.frontIncreViews(+id, _req?.user);

  }

前文已经说过，同一个用户多次刷新，如果不做处理，就会产生多次无效的阅读量。 因此，为了避免这种情况方式，我们需要为其增加一个用户文章id组合而成的标记，并设置在有效时间内不产生多次阅读量。

那么，有的掘友可能会产生一个疑问，如果用户未登录，那么以游客的身份去访问文章就不产生阅读记录了吗？

其实同理！

在我的项目中只是，要求需要用户登录后才能访问，
那么我这就会以 userID_postID_ 来组成标识区分用户和文章罢了。
而如果想以游客身份，我们可以获取用户 IP_postID 这样的组合来做标识即可

接下来说下postService中调用的frontIncreViews方法
直接贴代码：

 const res = await this.redisService.hashGet(`post_${id}`);



    if (res.viewCount === undefined) {

      const post = await this.postRepository.findOne({ where: { id } });



      post.viewCount++;



      await this.postRepository.update(id, { viewCount: post.viewCount });



      await this.redisService.hashSet(`post_${id}`, {

        viewCount: post.viewCount,

        likeCount: post.likeCount,

        collectCount: post.collectCount,

      });

      // 在用户访问文章的时候在 redis 存一个 10 分钟过期的标记，有这个标记的时候阅读量不增加

      await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);



      return post.viewCount;

    } else {

      const flag = await this.redisService.get(`user_${user.id}_post_${id}`);

      console.log(flag);

      if (flag) {

        return res.viewCount;

      }



      await this.redisService.hashSet(`post_${id}`, {

        ...res,

        viewCount: +res.viewCount + 1,

      });



      await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

      return +res.viewCount + 1;

    }

  }

const res = await this.redisService.hashGet(`post_${id}`);

使用Redis的哈希表结构，从键post_${id}中获取文章的信息，其中可能包含阅读量（viewCount）、点赞数（likeCount）和收藏数（collectCount）。

2. 检查Redis中是否存在阅读量:

if (res.viewCount === undefined) {

如果Redis中没有阅读量数据，说明这篇文章的阅读量还没有被初始化。

3. 从数据库中获取文章并增加阅读量:

const post = await this.postRepository.findOne({ where: { id } });

post.viewCount++;

await this.postRepository.update(id, { viewCount: post.viewCount });

从数据库中获取文章，然后增加阅读量，并更新数据库中的文章阅读量。

4. 将更新后的文章信息存回Redis:

await this.redisService.hashSet(`post_${id}`, {

  viewCount: post.viewCount,

  likeCount: post.likeCount,

  collectCount: post.collectCount,

});

将更新后的文章信息（包括新的阅读量、点赞数和收藏数）存回Redis的哈希表中。

5. 设置用户访问标记:

await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

在用户访问文章时，在Redis中设置一个带有10分钟过期时间的标记，用于防止在10分钟内重复增加阅读量。

6. 返回阅读量:

return post.viewCount;

返回更新后的阅读量。

7. 如果Redis中存在阅读量:

} else {

  const flag = await this.redisService.get(`user_${user.id}_post_${id}`);

  console.log(flag);

如果Redis中存在阅读量数据，则检查用户是否已经访问过该文章。

8. 检查用户访问标记:

if (flag) {

  return res.viewCount;

}

如果用户已经访问过该文章（标记存在），则直接返回当前阅读量，不增加。

9. 如果用户未访问过文章:

await this.redisService.hashSet(`post_${id}`, {

  ...res,

  viewCount: +res.viewCount + 1,

});

await this.redisService.set(`user_${user.id}_post_${id}`, 1, 10);

return +res.viewCount + 1;

如果用户未访问过该文章，则增加阅读量，并重新设置用户访问标记。然后返回更新后的阅读量。

简而言之，目的是在用户访问文章时，确保文章阅读量只增加一次，即使用户在短时间内多次访问。

NestJS使用定时任务包，实现redis数据同步到数据库中

有的掘友可能疑问，既然已经用redis来做阅读量记录了，为什么还要同步到数据库中，前文开始的时候，就已经提到过了，一旦我们的项目重启， redis 数据就没了，而数据库却有着“数据持久性的优良品质”。不像redis重启后，又是个新生儿。但是它们的互补，又是1+1大于2的那种。

好了，不废话了

一、引入定时任务包 @nestjs/schedule

npm install --save @nestjs/schedule

在 app.module.ts 引入

二、创建定时任务模块和服务

nest g module task 

nest g service task

你可以在同一个服务里面声明多个定时任务方法。在 NestJS 中，使用 @nestjs/schedule 库时，你只需要在服务类中为每个定时任务方法添加 @Cron() 装饰器，并指定相应的 cron 表达式。以下是一个示例，展示了如何在同一个服务中声明两个定时任务：

import { Injectable } from '@nestjs/common';

import { Cron, CronExpression } from '@nestjs/schedule';



@Injectable()

export class TasksService {

  // 第一个定时任务，每5秒执行一次

  @Cron(CronExpression.EVERY_5_SECONDS)

  handleEvery5Seconds() {

    console.log('Every 5 seconds task executed');

  }



  // 第二个定时任务，每10秒执行一次

  @Cron(CronExpression.EVERY_10_SECONDS)

  handleEvery10Seconds() {

    console.log('Every 10 seconds task executed');

  }

}

三、实现定时任务中同步文章阅读量的任务

更新文章的阅读数据

await this.postService.flushRedisToDB();

  // 查询出 key 对应的值，更新到数据库。 做定时任务的时候加上

  async flushRedisToDB() {

    const keys = await this.redisService.keys(`post_*`);

    console.log(keys);

    for (let i = 0; i < keys.length; i++) {

      const key = keys[i];



      const res = await this.redisService.hashGet(key);



      const [, id] = key.split('_');



      await this.postRepository.update(

        {

          id: +id,

        },

        {

          viewCount: +res.viewCount,

        },

      );

    }

  }

等到第二天，哈，数据就同步来了

访问：

而产生的后台数据：

抛出问题

如果能看到这里的掘友，若能接下这个问题，说明你已经掌握了吖

问题1：

如何实现一个批量返回redis键值对的方法（这个方法问题2需要用到）

问题2：

用户查询文章列表的时候，如何整理数据后返回文章阅读量呈现给用户查看

公众号：【可乐前端】，每天3分钟学习一个优秀的开源项目，分享web面试与实战知识。

前言

可乐是一名前端切图仔，最近他们团队需要做一个文章社区平台。由于人手不够，前后端部分都是由前端同学来实现，后端部分用的技术栈是 nest.js 。

某一个周一，领导希望做一个给文章点赞的功能，在文章列表页与文章详情页需要看到该文章的点赞总数，以及当前登录的用户有没有对该文章点赞，即用户与文章的点赞关系。

交代完之后，领导就去出差了。等领导回来时已是周五，他问可乐：这期的需求进展如何？

可乐回答：点赞的需求我做完了，其他的还没开始。

领导生气的说：为什么点赞这样的一个小功能你做了五天才做完？？？

可乐回答：领导息怒。。请听我细细道来

往期文章

仓库地址

• 切图仔做全栈：React&Nest.js 社区平台(一)——基础架构与邮箱注册、JWT 登录实现


• 切图仔做全栈：React&Nest.js社区平台(二)——👋手把手实现优雅的鉴权机制


• React&Nest.js全栈社区平台(三)——🐘对象存储是什么？为什么要用它？


• React&Nest.js社区平台(四)——✏️文章发布与管理实战


• React&Nest.js全栈社区平台(五)——👋封装通用分页Service实现文章流与详情

初步设计

对于上面的这个需求，我们提炼出来有三点最为重要的功能：

所以这里容易想到的是在文章表中冗余一个点赞数量字段 likes ，查询文章的时候一起把点赞总数带出来。

然后建一张 article_lile_relation 表，建立文章点赞与用户之间的关联关系。

上面的数据就表明了 id 为 2001 的用户点赞了 id 为 1001 的文章； id 为 2002 的用户对 id 为 1001 的文章取消了点赞。

这是对于这种关联关系需求最容易想到的、也是成本不高的解决方案，但在仔细思考了一番之后，我放弃了这种方案。原因如下：

基于上面的考虑，准备设计一个通用的点赞模块，以拓展后续各种业务的点赞需求。

表设计

首先来一张通用的点赞表， DDL 语句如下：

CREATE TABLE `like_records` (

  `id` int(11) NOT NULL AUTO_INCREMENT,

  `user_id` int(11) DEFAULT NULL,

  `target_id` int(11) DEFAULT NULL,

  `type` int(4) DEFAULT NULL,

  `created_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

  `updated_time` timestamp NULL DEFAULT CURRENT_TIMESTAMP,

  `value` int(4) DEFAULT '0',

  PRIMARY KEY (`id`),

  KEY `like_records_target_id_IDX` (`target_id`,`user_id`,`type`) USING BTREE,

  KEY `like_records_user_id_IDX` (`user_id`,`target_id`,`type`) USING BTREE

) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4;

解释一下上面各个字段的含义：

• id ：点赞记录的主键 id


• user_id ：点赞用户的 id


• target_id ：被点赞的文章 id


• type ：点赞类型：可能有文章、帖子、评论等


• value ：是否点赞， 1 点赞， 0 取消点赞


• created_time ：创建时间


• updated_time ：更新时间

前置知识

在设计好数据表之后，再来捋清楚这个业务的一些特定属性与具体实现方式：

所以可乐针对这样的业务特性上网查找了一些资料，发现有一些前置知识是他所欠缺的，我们一起来看看。

mysql事务

mysql 的事务是指一系列的数据库操作，这些操作要么全部成功执行，要么全部失败回滚。事务是用来确保数据库的完整性、一致性和持久性的机制之一。

在 mysql 中，事务具有以下四个特性，通常缩写为 ACID ：

这里以商品下单创建订单并扣除库存为例，演示一下 nest+typeorm 中的事务如何使用：

import { Injectable } from '@nestjs/common';

import { InjectEntityManager } from '@nestjs/typeorm';

import { EntityManager } from 'typeorm';

import { Order } from './order.entity';

import { Product } from './product.entity';



@Injectable()

export class OrderService {

  constructor(

    @InjectEntityManager()

    private readonly entityManager: EntityManager,

  ) {}



  async createOrderAndDeductStock(productId: number, quantity: number): Promise<Order> {

    return await this.entityManager.transaction(async transactionalEntityManager => {

      // 查找产品并检查库存是否充足

      const product = await transactionalEntityManager.findOne(Product, productId);

      if (!product || product.stock < quantity) {

        throw new Error('Product not found or insufficient stock');

      }



      // 创建订单

      const order = new Order();

      order.productId = productId;

      order.quantity = quantity;

      await transactionalEntityManager.save(order);



      // 扣除库存

      product.stock -= quantity;

      await transactionalEntityManager.save(product);



      return order;

    });

  }

}

this.entityManager.transaction 创建了一个事务，在异步函数中，如果发生错误， typeorm 会自动回滚事务；如果没有发生错误，typeorm 会自动提交事务。

在这个实例中，尝试获取库存并创建订单和减库存，如果任何一个地方出错异常抛出，则事务就会回滚，这样就保证了多表间数据的一致性。

分布式锁

分布式锁是一种用于在分布式系统中协调多个节点并保护共享资源的机制。在分布式系统中，由于涉及多个节点并发访问共享资源，因此需要一种机制来确保在任何给定时间只有一个节点能够访问或修改共享资源，以防止数据不一致或竞争条件的发生。

对于同一个用户对同一篇文章频繁的点赞/取消点赞请求，可以加分布式锁的机制，来规避一些问题：

在 redis 中实现分布式锁通常使用的是基于 SETNX 命令和 EXPIRE 命令的方式：

  async getLock(key: string) {

    const res = await this.redis.setnx(key, 'lock');

    if (res) {

        // 10秒锁过期

        await this.redis.expire(key, 10);

    }

    return res;

  }



  async unLock(key: string) {

    return this.del(key);

  }

redis中的set结构

redis 中的 set 是一种无序集合，用于存储多个不重复的字符串值，set 中的每个成员都是唯一的。

我们存储点赞关系的时候，需要用到 redis 中的 set 结构，存储的 key 与 value 如下：

article_1001:[uid1,uid2,uid3]

这就表示文章 id 为 1001 的文章，有用户 id 为 uid1 、 uid2 、 uid3 这三个用户点赞了。

常用的 set 结构操作命令包括：

• SADD key member [member ...]: 将一个或多个成员加入到集合中。


• SMEMBERS key: 返回集合中的所有成员。


• SISMEMBER key member: 检查成员是否是集合的成员。


• SCARD key: 返回集合元素的数量。


• SREM key member [member ...]: 移除集合中一个或多个成员。


• SPOP key [count]: 随机移除并返回集合中的一个或多个元素。


• SRANDMEMBER key [count]: 随机返回集合中的一个或多个元素，不会从集合中移除元素。


• SUNION key [key ...]: 返回给定所有集合的并集。


• SINTER key [key ...]: 返回给定所有集合的交集。


• SDIFF key [key ...]: 返回给定所有集合的差集。

下面举几个点赞场景的例子

redis事务

在 redis 中，事务是一组命令的有序序列，这些命令在执行时会被当做一个单独的操作来执行。即事务中的所有命令要么全部执行成功，要么全部执行失败，不存在部分执行的情况。

以下是 redis 事务的主要命令：

比如说下面的代码给集合增加元素，并更新集合的过期时间，可以如下使用 redis 的事务去执行它：

  const pipeline = this.redisService.multi();

  const setKey = this.getSetKey(targetId, type);

  if (value === ELike.LIKE) {

    pipeline.sadd(setKey, userId);

  } else {

    pipeline.srem(setKey, userId);

  }

  pipeline.expire(setKey, this.ttl);

  await pipeline.exec();

流程图设计

在了解完这些前置知识之后，可乐开始画一些实现的流程图。

首先是点赞/取消点赞接口的流程图：

简单解释下上面的流程图：

然后是获取点赞数量和点赞关系的接口

简单解释下上面的流程图：

代码实现

在所有的设计完毕之后，可以做最后的代码实现了。分别来实现点赞操作与点赞数量接口。这里主要关注 service 层的实现即可。

点赞/取消点赞接口

  async toggleLike(params: {

    userId: number;

    targetId: number;

    type: ELikeType;

    value: ELike;

  }) {

    const { userId, targetId, type, value } = params;

    const LOCK_KEY = `${userId}::${targetId}::${type}::toggleLikeLock`;

    const canGetLock = await this.redisService.getLock(LOCK_KEY);

    if (!canGetLock) {

      console.log('获取锁失败');

      await wait();

      return this.toggleLike(params);

    }

    const record = await this.likeRepository.findOne({

      where: { userId, targetId, type },

    });

    if (record && record.value === value) {

      await this.redisService.unLock(LOCK_KEY);

      throw Error('不可重复操作');

    }



    await this.entityManager.transaction(async (transactionalEntityManager) => {

      if (!record) {

        const likeEntity = new LikeEntity();

        likeEntity.targetId = targetId;

        likeEntity.type = type;

        likeEntity.userId = userId;

        likeEntity.value = value;

        await transactionalEntityManager.save(likeEntity);

      } else {

        const id = record.id;

        await transactionalEntityManager.update(LikeEntity, { id }, { value });

      }

      const isSuccess = await this.tryToFreshCache(params);



      if (!isSuccess) {

        await this.redisService.unLock(LOCK_KEY);

        throw Error('操作失败');

      }

    });

    await this.redisService.unLock(LOCK_KEY);

    return true;

  }

  

private async tryToFreshCache(

    params: {

      userId: number;

      targetId: number;

      type: ELikeType;

      value: ELike;

    },

    retry = 3,

  ) {

    if (retry === 0) {

      return false;

    }

    const { targetId, type, value, userId } = params;

    try {

      const pipeline = this.redisService.multi();

      const setKey = this.getSetKey(targetId, type);

      if (value === ELike.LIKE) {

        pipeline.sadd(setKey, userId);

      } else {

        pipeline.srem(setKey, userId);

      }

      pipeline.expire(setKey, this.ttl);

      await pipeline.exec();

      return true;

    } catch (error) {

      console.log('tryToFreshCache error', error);

      await wait();

      return this.tryToFreshCache(params, retry - 1);

    }

  }

可以参照流程图来看这部分实现代码，基本实现就是使用 mysql 事务去更新点赞信息表，然后去更新 redis 中的点赞信息，如果更新失败则回滚事务，保证数据的一致性。

获取点赞数量、点赞关系接口

  async getLikes(params: {

    targetId: number;

    type: ELikeType;

    userId: number;

  }) {

    const { targetId, type, userId } = params;

    const setKey = this.getSetKey(targetId, type);

    const cacheExsit = await this.redisService.exist(setKey);

    if (!cacheExsit) {

      await this.getLikeFromDbAndSetCache(params);

    }

    const count = await this.redisService.getSetLength(setKey);

    const isLike = await this.redisService.isMemberOfSet(setKey, userId);

    return { count, isLike };

  }



  private async getLikeFromDbAndSetCache(params: {

    targetId: number;

    type: ELikeType;

    userId: number;

  }) {

    const { targetId, type, userId } = params;

    const LOCK_KEY = `${targetId}::${type}::getLikesLock`;

    const canGetLock = await this.redisService.getLock(LOCK_KEY);

    if (!canGetLock) {

      console.log('获取锁失败');

      await wait();

      return this.getLikeFromDbAndSetCache(params);

    }

    const setKey = this.getSetKey(targetId, type);

    const cacheExsit = await this.redisService.exist(setKey);

    if (cacheExsit) {

      await this.redisService.unLock(LOCK_KEY);

      return true;

    }

    const data = await this.likeRepository.find({

      where: {

        targetId,

        userId,

        type,

        value: ELike.LIKE,

      },

      select: ['userId'],

    });

    if (data.length !== 0) {

      await this.redisService.setAdd(

        setKey,

        data.map((item) => item.userId),

        this.ttl,

      );

    }

    await this.redisService.unLock(LOCK_KEY);

    return true;

  }

由于读操作相当频繁，所以这里应当多使用缓存，少查询数据库。读点赞信息时，先查 redis 中有没有，如果没有，则从 mysql 同步到 redis 中，同步的过程中也使用到了分布式锁，防止一开始没缓存时请求大量打到 mysql 。

同时，如果所有文章的点赞信息都同时存在 redis 中，那 redis 的存储压力会比较大，所以这里会给相关的 key 设置一个过期时间。当用户重新操作点赞时，会更新这个过期时间。保障缓存的数据都是相对热点的数据。

通过组装数据，获取点赞信息的返回数据结构如下：

返回一个 map ，其中 key 文章 id ， value 里面是该文章的点赞数量以及当前用户是否点赞了这篇文章。

前端实现

文章流列表发生变化的时候，可以监听列表的变化，然后去获取点赞的信息：

useEffect(() => {

    if (!article.list) {

      return;

    }

    const shouldGetLikeIds = article.list

      .filter((item: any) => !item.likeInfo)

      .map((item: any) => item.id);

    if (shouldGetLikeIds.length === 0) {

      return;

    }

    console.log("shouldGetLikeIds", shouldGetLikeIds);

    getLikes({

      targetIds: shouldGetLikeIds,

      type: 1,

    }).then((res) => {

      const map = res.data;

      const newList = [...article.list];

      for (let i = 0; i < newList.length; i++) {

        if (!newList[i].likeInfo && map[newList[i].id]) {

          newList[i].likeInfo = map[newList[i].id];

        }

      }

      const newArticle = { ...article };

      newArticle.list = newList;

      setArticle(newArticle);

    });

  }, [article]);

点赞操作的时候前端也需要加锁，接口执行完毕了再把锁释放。

   <Space

    onClick={(e) => {

      e.stopPropagation();

      if (lockMap.current?.[item.id]) {

        return;

      }

      lockMap.current[item.id] = true;

      const oldValue = item.likeInfo.isLike;

      const newValue = !oldValue;

      const updateValue = (value: any) => {

        const newArticle = { ...article };

        const newList = [...newArticle.list];

        const current = newList.find(

          (_) => _.id === item.id

        );

        current.likeInfo.isLike = value;

        if (value) {

          current.likeInfo.count++;

        } else {

          current.likeInfo.count--;

        }

        setArticle(newArticle);

      };

      updateValue(newValue);

      toggleLike({

        targetId: item.id,

        value: Number(newValue),

        type: 1,

      })

        .catch(() => {

          updateValue(oldValue);

        })

        .finally(() => {

          lockMap.current[item.id] = false;

        });

    }}

  >

    <LikeOutlined

      style={

        item.likeInfo.isLike ? { color: "#1677ff" } : {}

      }

    />

    {item.likeInfo.count}

  </Space>

解释

可乐：从需求分析考虑、然后研究网上的方案并学习前置知识，再是一些环境的安装，最后才是前后端代码的实现，领导，我这花了五天不过份吧。

领导（十分无语）：我们平台本来就没几个用户、没几篇文章，本来就是一张关联表就能解决的问题，你又搞什么分布式锁又搞什么缓存，还花了那么多天时间。我不管啊，剩下没做的需求你得正常把它正常做完上线，今天周五，周末你也别休息了，过来加班吧。

最后

以上就是本文的全部内容，如果你觉得有意思的话，点点关注点点赞吧～

@RestControllerAdvice

public class GlobalExceptionHandler {



    /**

     *  参数校检异常

     * @param e

     * @return

     */

    @ExceptionHandler(value = MethodArgumentNotValidException.class)

    public ResponseResult handle(MethodArgumentNotValidException e) {

        BindingResult bindingResult = e.getBindingResult();



        StringJoiner joiner = new StringJoiner(";");



        for (ObjectError error : bindingResult.getAllErrors()) {

            String code = error.getCode();

            String[] codes = error.getCodes();



            String property = codes[1];

            property = property.replace(code ,"").replaceFirst(".","");



            String defaultMessage = error.getDefaultMessage();

            joiner.add(property+defaultMessage);

        }

        return handleException(joiner.toString());

    }



    private ResponseResult handleException(String msg) {

        ResponseResult result = new ResponseResult<>();

        result.setMessage(msg);

        result.setCode(500);

        return result;

    }

}

public interface CreationGr0up {

}

public interface UpdateGr0up {

}

创建一个UserBean用户类，分别校验 username 字段不能为空和id字段必须大于0，然后加上CreationGr0up和 UpdateGr0up 分组。

/**

 * @author 公众号-索码理(suncodernote)

 */

@Data

public class UserBean {



    @NotEmpty( groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    @Email(message = "邮箱格式不正确")

    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;

}

3. 创建接口

在ValidationController 中新建两个接口 updateUser 和 createUser：

@RestController

@RequestMapping("validation")

public class ValidationController {



    @GetMapping("updateUser")

    public UserBean updateUser(@Validated({UpdateGr0up.class})  UserBean userBean){

        return userBean;

    }



    @GetMapping("createUser")

    public UserBean createUser(@Validated({CreationGr0up.class})  UserBean userBean){

        return userBean;

    }

}

4. 测试

先对 createUser接口进行测试，我们将id的值设置为0，也就是不满足id必须大于0的条件，同样 username 不传值，即不满足 username 不能为空的条件。  通过测试结果我们可以看到，虽然id没有满足条件，但是并没有提示，只提示了username不能为空。

再对 updateUser接口进行测试，条件和测试 createUser接口的条件一样，再看测试结果，和 createUser接口测试结果完全相反，只提示了id最小不能小于1。 

至此，分组功能就演示完毕了。

嵌套校验

介绍嵌套校验之前先看一下两个概念：

有这样一个需求，在保存用户时，用户地址必须要填写。下面来简单看下示例：

在AddressBean 设置 country和city两个属性为必填项。

@Data

public class AddressBean {



    @NotBlank

    private String country;



    @NotBlank

    private String city;

}

2. 修改用户类，将AddressBean作为用户类的一个嵌套属性

特别提示：想要嵌套校验生效，必须在嵌套属性上加 @Valid 注解。

@Data

public class UserBean {



    @NotEmpty(groups = {CreationGr0up.class})

    private String username;



    @Min(value = 18)

    private Integer age;



    private String email;



    @Min(value  = 1 ,groups = {UpdateGr0up.class})

    private Long id;



	//嵌套验证必须要加上@Valid

    @Valid

    @NotNull

    private AddressBean address;

}

3. 创建一个嵌套校验测试接口

@PostMapping("nestValid")

public UserBean nestValid(@Validated @RequestBody UserBean userBean){

    System.out.println(userBean);

    return userBean;

}

4. 测试

我们在传参时，只传 country字段，通过响应结果可以看到提示了city 字段不能为空。 

可以看到使用了 @Valid 注解来对 Address 对象进行验证，这会触发对其中的 Address 对象的验证。通过这种方式，可以确保嵌套属性内部的对象也能够参与到整体对象的验证过程中，从而提高验证的完整性和准确性。

总结

本文介绍了@Valid注解和@Validated注解的不同，同时也进一步介绍了Springboot 参数校验的使用。不管是 JSR-303、JSR-380又或是 Hibernate Validator ，它们提供的参数校验注解都是有限的，实际工作中这些注解可能是不够用的，这个时候就需要我们自定义参数校验了。下篇文章将介绍一下如何自定义一个参数校验器。

MinIO： 数据宇宙的超级存储引擎，解锁云原生潜能- 精选真开源，释放新价值。

概览

MinIO，这一高性能分布式对象存储系统的佼佼者，正以开源的力量重塑企业数据存储的版图。它设计轻巧且完全兼容Amazon S3接口，成为连接全球开发者与企业的桥梁，提供了一个既强大又灵活的数据管理平台。超越传统存储桶的范畴，MinIO是专为应对大规模数据挑战而生，尤其适用于AI深度学习、大数据分析等高负载场景，其单个对象高达5TB的存储容量设计，确保了数据密集应用运行无阻，流畅高效。

无论是部署于云端、边缘计算环境还是本地服务器，MinIO展现了极高的适配性和灵活性。它以超简单的安装步骤、直观的管理界面以及平滑的扩展能力，极大地降低了企业构建复杂数据架构的门槛。利用MinIO，企业能够快速部署数据湖，以集中存储海量数据，便于分析挖掘；构建高效的内容分发网络（CDN），加速内容的全球分发；或建立可靠的备份存储方案，确保数据资产的安全无虞。

MinIO的特性还包括自动数据分片、跨区域复制、以及强大的数据持久性和高可用性机制，这些都为数据的全天候安全与访问提供了坚实保障。此外，其微服务友好的架构，使得集成到现有的云原生生态系统中变得轻而易举，加速了DevOps流程，提升了整体IT基础设施的响应速度和灵活性。

主要功能

你可以进入官方网站下载体验：min.io/download

• 高性能存储

• 分布式架构

• 全面的S3兼容性

• 安全与合规

• 简易管理与监控

信息

截至发稿概况如下：

• 软件地址：github.com/minio/minio


• 软件协议：AGPL 3.0


• 编程语言：

• 收藏数量：44.3K

面对不断增长的数据管理挑战，MinIO不仅是一个存储解决方案，更是企业在数字化转型旅程中的核心支撑力量，助力各行各业探索数据价值的无限可能。无论是优化存储成本、提升数据处理效率，还是确保数据安全与合规，MinIO持续推动技术边界，邀请每一位技术探索者加入其活跃的开源社区，共同参与讨论，贡献智慧，共同塑造数据存储的未来。

尽管MinIO凭借其卓越的性能与易于使用的特性在存储领域独树一帜，但面对数据量的指数级增长和环境的日益复杂，一系列新挑战浮出水面。首要任务是在海量数据中实现高效的数据索引与查询机制，确保信息的快速提取与分析。其次，在混合云及多云部署的趋势下，如何平滑实现数据在不同平台间的迁移与实时同步，成为提升业务连续性和灵活性的关键。再者，数据安全虽为根基，但在成本控制上也不可忽视，优化存储策略，在强化防护的同时降低开支，实现存储经济性与安全性的完美平衡，是当前亟待探讨与解决的课题。这些问题不仅考验着技术的极限，也为MinIO及其用户社区带来了新的研究方向与实践机遇。

热烈欢迎各位在评论区分享交流心得与见解！！！

这一章，我们将简单的介绍以太坊中的数字签名ECDSA，以及如何利用它发放NFT白名单。代码中的ECDSA库由OpenZeppelin的同名库简化而成。

数字签名

如果你用过opensea交易NFT，对签名就不会陌生。下图是小狐狸（metamask）钱包进行签名时弹出的窗口，它可以证明你拥有私钥的同时不需要对外公布私钥。

以太坊使用的数字签名算法叫双椭圆曲线数字签名算法（ECDSA），基于双椭圆曲线“私钥-公钥”对的数字签名算法。它主要起到了三个作用：

ECDSA合约

ECDSA标准中包含两个部分：

私钥: 0x227dbb8586117d55284e26620bc76534dfbd2394be34cf4a09cb775d593b6f2b

公钥: 0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2

消息: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

以太坊签名消息: 0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

签名: 0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

创建签名

1. 打包消息：  在以太坊的ECDSA标准中，被签名的消息是一组数据的keccak256哈希，为bytes32类型。我们可以把任何想要签名的内容利用abi.encodePacked()函数打包，然后用keccak256()计算哈希，作为消息。我们例子中的消息是由一个address类型变量和一个uint256类型变量得到的：

    /*

     * 将mint地址（address类型）和tokenId（uint256类型）拼成消息msgHash

     * _account: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

     * _tokenId: 0

     * 对应的消息msgHash: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

     */

    function getMessageHash(address _account, uint256 _tokenId) public pure returns(bytes32){

        return keccak256(abi.encodePacked(_account, _tokenId));

    }

2. 计算以太坊签名消息：  消息可以是能被执行的交易，也可以是其他任何形式。为了避免用户误签了恶意交易，EIP191提倡在消息前加上"\x19Ethereum Signed Message:\n32"字符，并再做一次keccak256哈希，作为以太坊签名消息。经过toEthSignedMessageHash()函数处理后的消息，不能被用于执行交易:

    /**

     * @dev 返回 以太坊签名消息

     * `hash`：消息

     * 遵从以太坊签名标准：https://eth.wiki/json-rpc/API#eth_sign[`eth_sign`]

     * 以及`EIP191`:https://eips.ethereum.org/EIPS/eip-191`

     * 添加"\x19Ethereum Signed Message:\n32"字段，防止签名的是可执行交易。

     */

    function toEthSignedMessageHash(bytes32 hash) internal pure returns (bytes32) {

        // 哈希的长度为32

        return keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash));

    }

处理后的消息为：

以太坊签名消息: 0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

3-1. 利用钱包签名：  日常操作中，大部分用户都是通过这种方式进行签名。在获取到需要签名的消息之后，我们需要使用metamask钱包进行签名。metamask的personal_sign方法会自动把消息转换为以太坊签名消息，然后发起签名。所以我们只需要输入消息和签名者钱包account即可。需要注意的是输入的签名者钱包account需要和metamask当前连接的account一致才能使用。

因此首先把例子中的私钥导入到小狐狸钱包，然后打开浏览器的console页面：Chrome菜单-更多工具-开发者工具-Console。在连接钱包的状态下（如连接opensea，否则会出现错误），依次输入以下指令进行签名：

ethereum.enable()

account = "0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2"

hash = "0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c"

ethereum.request({method: "personal_sign", params: [account, hash]})

在返回的结果中（Promise的PromiseResult）可以看到创建好的签名。不同账户有不同的私钥，创建的签名值也不同。利用教程的私钥创建的签名如下所示：

0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

3-2. 利用web3.py签名：  批量调用中更倾向于使用代码进行签名，以下是基于web3.py的实现。

from web3 import Web3, HTTPProvider

from eth_account.messages import encode_defunct



private_key = "0x227dbb8586117d55284e26620bc76534dfbd2394be34cf4a09cb775d593b6f2b"

address = "0x5B38Da6a701c568545dCfcB03FcB875f56beddC4"

rpc = 'https://rpc.ankr.com/eth'

w3 = Web3(HTTPProvider(rpc))



#打包信息

msg = Web3.solidityKeccak(['address','uint256'], [address,0])

print(f"消息：{msg.hex()}")

#构造可签名信息

message = encode_defunct(hexstr=msg.hex())

#签名

signed_message = w3.eth.account.sign_message(message, private_key=private_key)

print(f"签名：{signed_message['signature'].hex()}")

运行的结果如下所示。计算得到的消息，签名和前面的案例一致。

消息：0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

签名：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

验证签名

为了验证签名，验证者需要拥有消息，签名，和签名使用的公钥。我们能验证签名的原因是只有私钥的持有者才能够针对交易生成这样的签名，而别人不能。

4. 通过签名和消息恢复公钥： 签名是由数学算法生成的。这里我们使用的是rsv签名，签名中包含r, s, v三个值的信息。而后，我们可以通过r, s, v及以太坊签名消息来求得公钥。下面的recoverSigner()函数实现了上述步骤，它利用以太坊签名消息 _msgHash和签名 _signature恢复公钥（使用了简单的内联汇编）：

    // @dev 从_msgHash和签名_signature中恢复signer地址

    function recoverSigner(bytes32 _msgHash, bytes memory _signature) internal pure returns (address){

        // 检查签名长度，65是标准r,s,v签名的长度

        require(_signature.length == 65, "invalid signature length");

        bytes32 r;

        bytes32 s;

        uint8 v;

        // 目前只能用assembly (内联汇编)来从签名中获得r,s,v的值

        assembly {

            /*

            前32 bytes存储签名的长度 (动态数组存储规则)

            add(sig, 32) = sig的指针 + 32

            等效为略过signature的前32 bytes

            mload(p) 载入从内存地址p起始的接下来32 bytes数据

            */

            // 读取长度数据后的32 bytes

            r := mload(add(_signature, 0x20))

            // 读取之后的32 bytes

            s := mload(add(_signature, 0x40))

            // 读取最后一个byte

            v := byte(0, mload(add(_signature, 0x60)))

        }

        // 使用ecrecover(全局函数)：利用 msgHash 和 r,s,v 恢复 signer 地址

        return ecrecover(_msgHash, v, r, s);

    }

参数分别为：

// 以太坊签名消息

_msgHash：0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

// 签名

_signature：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

5. 对比公钥并验证签名：  接下来，我们只需要比对恢复的公钥与签名者公钥_signer是否相等：若相等，则签名有效；否则，签名无效：

    /**

     * @dev 通过ECDSA，验证签名地址是否正确，如果正确则返回true

     * _msgHash为消息的hash

     * _signature为签名

     * _signer为签名地址

     */

    function verify(bytes32 _msgHash, bytes memory _signature, address _signer) internal pure returns (bool) {

        return recoverSigner(_msgHash, _signature) == _signer;

    }

参数分别为：

_msgHash：0xb42ca4636f721c7a331923e764587e98ec577cea1a185f60dfcc14dbb9bd900b

_signature：0x390d704d7ab732ce034203599ee93dd5d3cb0d4d1d7c600ac11726659489773d559b12d220f99f41d17651b0c1c6a669d346a397f8541760d6b32a5725378b241c

_signer：0xe16C1623c1AA7D919cd2241d8b36d9E79C1Be2A2

利用签名发放白名单

NFT项目方可以利用ECDSA的这个特性发放白名单。由于签名是链下的，不需要gas。方法非常简单，项目方利用项目方账户把白名单发放地址签名（可以加上地址可以铸造的tokenId）。然后mint的时候利用ECDSA检验签名是否有效，如果有效，则给他mint。

SignatureNFT合约实现了利用签名发放NFT白名单。

状态变量

合约中共有两个状态变量：

• signer：公钥，项目方签名地址。


• mintedAddress是一个mapping，记录了已经mint过的地址。

函数

合约中共有4个函数：

• 构造函数初始化NFT的名称和代号，还有ECDSA的签名地址signer。


• mint()函数接受地址address，tokenId和_signature三个参数，验证签名是否有效：如果有效，则把tokenId的NFT铸造给address地址，并将它记录到mintedAddress。它调用了getMessageHash()，ECDSA.toEthSignedMessageHash()和verify()函数。


• getMessageHash()函数将mint地址（address类型）和tokenId（uint256类型）拼成消息。


• verify()函数调用了ECDSA库的verify()函数，来进行ECDSA签名验证。

contract SignatureNFT is ERC721 {

    address immutable public signer; // 签名地址

    mapping(address => bool) public mintedAddress;   // 记录已经mint的地址



    // 构造函数，初始化NFT合集的名称、代号、签名地址

    constructor(string memory _name, string memory _symbol, address _signer)

    ERC721(_name, _symbol)

    {

        signer = _signer;

    }



    // 利用ECDSA验证签名并mint

    function mint(address _account, uint256 _tokenId, bytes memory _signature)

    external

    {

        bytes32 _msgHash = getMessageHash(_account, _tokenId); // 将_account和_tokenId打包消息

        bytes32 _ethSignedMessageHash = ECDSA.toEthSignedMessageHash(_msgHash); // 计算以太坊签名消息

        require(verify(_ethSignedMessageHash, _signature), "Invalid signature"); // ECDSA检验通过

        require(!mintedAddress[_account], "Already minted!"); // 地址没有mint过

        _mint(_account, _tokenId); // mint

        mintedAddress[_account] = true; // 记录mint过的地址

    }



    /*

     * 将mint地址（address类型）和tokenId（uint256类型）拼成消息msgHash

     * _account: 0x5B38Da6a701c568545dCfcB03FcB875f56beddC4

     * _tokenId: 0

     * 对应的消息: 0x1bf2c0ce4546651a1a2feb457b39d891a6b83931cc2454434f39961345ac378c

     */

    function getMessageHash(address _account, uint256 _tokenId) public pure returns(bytes32){

        return keccak256(abi.encodePacked(_account, _tokenId));

    }



    // ECDSA验证，调用ECDSA库的verify()函数

    function verify(bytes32 _msgHash, bytes memory _signature)

    public view returns (bool)

    {

        return ECDSA.verify(_msgHash, _signature, signer);

    }

}

总结

这一讲，我们介绍了以太坊中的数字签名ECDSA，如何利用ECDSA创建和验证签名，还有ECDSA合约，以及如何利用它发放NFT白名单。代码中的ECDSA库由OpenZeppelin的同名库简化而成。

• 由于签名是链下的，不需要gas，因此这种白名单发放模式比Merkle Tree模式还要经济；


• 但由于用户要请求中心化接口去获取签名，不可避免的牺牲了一部分去中心化；


• 额外还有一个好处是白名单可以动态变化，而不是提前写死在合约里面了，因为项目方的中心化后端接口可以接受任何新地址的请求并给予白名单签名。

今天在网上逛的时候看到一个问题，没想到大家讨论的很热烈，就是标题中这个：

localhost和127.0.0.1的区别是什么？

前端同学本地调试的时候，应该没少和localhost打交道吧，只需要执行 npm run 就能在浏览器中打开你的页面窗口，地址栏显示的就是这个 http://localhost:xxx/index.html

可能大家只是用，也没有去想过这个问题。

联想到我之前合作过的一些开发同学对它们俩的区别也没什么概念，所以我觉得有必要普及下。

localhost是什么呢？

localhost是一个域名，和大家上网使用的域名没有什么本质区别，就是方便记忆。

只是这个localhost的有效范围只有本机，看名字也能知道：local就是本地的意思。

张三和李四都可以在各自的机器上使用localhost，但获取到的也是各自的页面内容，不会相互打架。

从域名到程序

要想真正的认清楚localhost，我们还得从用户是如何通过域名访问到程序说起。

以访问百度为例。

1、当我们在浏览器输入 baidu.com 之后，浏览器首先去DNS中查询 baidu.com 的IP地址。

为什么需要IP地址呢？打个比方，有个人要寄快递到你的公司，快递单上会填写：公司的通讯地址、公司名称、收件人等信息，实际运输时快递会根据通信地址进行层层转发，最终送到收件人的手中。网络通讯也是类似的，其中域名就像公司名称，IP地址就像通信地址，在网络的世界中只有通过IP地址才能找到对应的程序。

DNS就像一个公司黄页，其中记录着每个域名对应的IP地址，当然也有一些域名可能没做登记，就找不到对应的IP地址，还有一些域名可能会对应多个IP地址，DNS会按照规则自动返回一个。我们购买了域名之后，一般域名服务商会提供一个域名解析的功能，就是把域名和对应的IP地址登记到DNS中。

这里的IP地址从哪里获取呢？每台上网的电脑都会有1个IP地址，但是个人电脑的IP地址一般是不行的，个人电脑的IP地址只适合内网定位，就像你公司内部的第几栋第几层，公司内部人明白，但是直接发给别人，别人是找不到你的。如果你要对外部提供服务，比如百度这种，你就得有公网的IP地址，这个IP地址一般由网络服务运营商提供，比如你们公司使用联通上网，那就可以让联通给你分配一个公网IP地址，绑定到你们公司的网关服务器上，网关服务器就像电话总机，公司内部的所有网络通信都要通过它，然后再在网关上设置转发规则，将网络请求转发到提供网络服务的机器上。

2、有了IP地址之后，浏览器就会向这个IP地址发起请求，通过操作系统打包成IP请求包，然后发送到网络上。网络传输有一套完整的路由协议，它会根据你提供的IP地址，经过路由器的层层转发，最终抵达绑定该IP的计算机。

3、计算机上可能部署了多个网络应用程序，这个请求应该发给哪个程序呢？这里有一个端口的概念，每个网络应用程序启动的时候可以绑定一个或多个端口，不同的网络应用程序绑定的端口不能重复，再次绑定时会提示端口被占用。通过在请求中指定端口，就可以将消息发送到正确的网络处理程序。

但是我们访问百度的时候没有输入端口啊？这是因为默认不输入就使用80和443端口，http使用80，https使用443。我们在启动网络程序的时候一定要绑定一个端口的，当然有些框架会自动选择一个计算机上未使用的端口。

localhost和127.0.0.1的区别是什么？

有了上边的知识储备，我们就可以很轻松的搞懂这个问题了。

localhost是域名，上文已经说过了。

127.0.0.1 呢？是IP地址，当前机器的本地IP地址，且只能在本机使用，你的计算机不联网也可以用这个IP地址，就是为了方便开发测试网络程序的。我们调试时启动的程序就是绑定到这个IP地址的。

这里简单说下，我们经常看到的IP地址一般都是类似 X.X.X.X 的格式，用"."分成四段。其实它是一个32位的二进制数，分成四段后，每一段是8位，然后每一段再转换为10进制的数进行显示。

那localhost是怎么解析到127.0.0.1的呢？经过DNS了吗？没有。每台计算机都可以使用localhost和127.0.0.1，这没办法让DNS来做解析。

那就让每台计算机自己解决了。每台计算机上都有一个host文件，其中写死了一些DNS解析规则，就包括 localhost 到 127.0.0.1 的解析规则，这是一个约定俗成的规则。

如果你不想用localhost，那也可以，随便起个名字，比如 wodehost，也解析到 127.0.0.1 就行了。

甚至你想使用 baidu.com 也完全可以，只是只能自己自嗨，对别人完全没有影响。

域名的等级划分

localhost不太像我们平常使用的域名，比如 http://www.juejin.cn 、baidu.com、csdn.net, 这里边的 www、cn、com、net都是什么意思？localhost为什么不需要？

域名其实是分等级的，按照等级可以划分为顶级域名、二级域名和三级域名...

顶级域名（TLD）：顶级域名是域名系统中最高级别的域名。它位于域名的最右边，通常由几个字母组成。顶级域名分为两种类型：通用顶级域名和国家顶级域名。常见的通用顶级域名包括表示工商企业的.com、表示网络提供商的.net、表示非盈利组织的.org等，而国家顶级域名则代表特定的国家或地区，如.cn代表中国、.uk代表英国等。

二级域名（SLD）：二级域名是在顶级域名之下的一级域名。它是由注册人自行选择和注册的，可以是个性化的、易于记忆的名称。例如，juejin.cn 就是二级域名。我们平常能够申请到的也是这种。目前来说申请 xxx.com、xxx.net、xxx.cn等等域名，其实大家不太关心其顶级域名com\net\cn代表的含义，看着简短好记是主要诉求。

三级域名（3LD）：三级域名是在二级域名之下的一级域名。它通常用于指向特定的服务器或子网。例如，在blog.example.com中，blog就是三级域名。www是最常见的三级域名，用于代表网站的主页或主站点，不过这只是某种流行习惯，目前很多网站都推荐直接使用二级域名访问了。

域名级别还可以进一步细分，大家可以看看企业微信开放平台这个域名：developer.work.weixin.qq.com，com代表商业，qq代表腾讯，weixin代表微信，work代表企业微信，developer代表开发者。这种逐层递进的方式有利于域名的分配管理。

按照上边的等级定义，我们可以说localhost是一个顶级域名，只不过它是保留的顶级域，其唯一目的是用于访问当前计算机。

多网站共用一个IP和端口

上边我们说不同的网络程序不能使用相同的端口，其实是有办法突破的。

以前个人博客比较火的时候，大家都喜欢买个虚拟主机，然后部署个开源的博客程序，抒发一下自己的感情。为了挣钱，虚拟主机的服务商会在一台计算机上分配N多个虚拟主机，大家使用各自的域名和默认的80端口进行访问，也都相安无事。这是怎么做到的呢？

如果你有使用Nginx、Apache或者IIS等Web服务器的相关经验，你可能会接触到主机头这个概念。主机头其实就是一个域名，通过设置主机头，我们的程序就可以共用1个网络端口。

首先在Nginx等Web程序中部署网站时，我们会进行一些配置，此时在主机头中写入网站要使用的域名。

然后Nginx等Web服务器启动的时候，会把80端口占为己有。

然后当某个网站的请求到达Nginx的80端口时，它会根据请求中携带的域名找到配置了对应主机头的网络程序。

然后再转发到这个网络程序，如果网络程序还没有启动，Nginx会把它拉起来。

私有IP地址

除了127.0.0.1，其实还有很多私有IP地址，比如常见的 192.168.x.x。这些私有IP地址大部分都是为了在局域网内使用而预留的，因为给每台计算机都分配一个独立的IP不太够用，所以只要局域网内不冲突，大家就可劲的用吧。你公司可以用 192.168.1.1，我公司也可以用192.168.1.1，但是如果你要访问我，就得通过公网IP进行转发。

大家常用的IPv4私有IP地址段分为三类：

A类：从10.0.0.0至10.255.255.255

B类：从172.16.0.0至172.31.255.255

C类：从192.168.0.0至192.168.255.255。

这些私有IP地址仅供局域网内部使用，不能在公网上使用。

--

除了上述三个私有的IPv4地址段外，还有一些保留的IPv4地址段：

用于本地回环测试的127.0.0.0至127.255.255.255地址段，其中就包括题目中的127.0.0.1，如果你喜欢也可以给自己分配一个127.0.0.2的IP地址，效果和127.0.0.1一样。

用于局域网内部的169.254.0.0至169.254.255.255地址段，这个很少接触到，如果你的电脑连局域网都上不去，可能会看到这个IP地址，它是临时分配的一个局域网地址。

这些地址段也都不能在公网上使用。

--

近年来，还有一个现象，就是你家里或者公司里上网时，光猫或者路由器对外的IPv4地址也不是公网IP了，这时候获得的可能是一个类似 100.64.x.x 的地址，这是因为随着宽带的普及，运营商手里的公网IP也不够了，所以运营商又加了一层局域网，而100.64.0.0 这个网段是专门分给运营商做局域网用的。如果你使用阿里云等公有云，一些云产品的IP地址也可能是这个，这是为了将客户的私有网段和公有云厂商的私有网段进行有效的区分。

--

其实还有一些不常见的专用IPv4地址段，完整的IP地址段定义可以看这里：http://www.iana.org/assignments…

IPv6

你可能也听说过IPv6，因为IPv4可分配的地址太少了，不够用，使用IPv6甚至可以为地球上的每一粒沙子分配一个IP。只是喊了很多年，大家还是喜欢用IPv4，这里边原因很多，这里就不多谈了。

IPv6地址类似：XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX

它是128位的，用":"分成8段，每个X是一个16进制数（取值范围：0-F），IPv6地址空间相对于IPv4地址有了极大的扩充。比如：2001:0db8:3c4d:0015:0000:0000:1a2f:1a2b 就是一个有效的IPv6地址。

关于IPv6这里就不多说了，有兴趣的可以再去研究下。

关注萤火架构，加速技术提升！

早前搭过一个wiki (可点击wiki.dashen.tech 查看),用于"团队协作与知识分享".把游客账号给一位前同事,其告知登录出错.

用我记录的账号密码登录,同样报错; 打开数据库一看,疑惑全消.

To recover your lost Database and avoid leaking it: Send us 0.05 Bitcoin (BTC) to our Bitcoin address 3F4hqV3BRYf9JkPasL8yUPSQ5ks3FF3tS1 and contact us by Email with your Server IP or Domain name and a Proof of Payment. Your Database is downloaded and backed up on our servers. Backups that we have right now: mm_wiki, shuang. If we dont receive your payment in the next 10 Days, we will make your database public or use them otherwise.

(按照今日比特币价格,0.05比特币折合人民币4 248.05元..)

大多时候不使用该服务器上安装的mysql,因而账号和端口皆为默认,密码较简单且常见,为在任何地方navicat也可连接,去掉了ip限制...对方写一个脚本,扫描各段ip地址,用常见的几个账号和密码去"撞库",几千几万个里面,总有一两个能得手.

被窃取备份而后删除的两个库,一个是来搭建该wiki系统,另一个是用来亲测mysql主从同步,详见此篇,价值都不大

实践告诉我们，不要用默认账号，不要用简单密码，要做ip限制。…

• 登录服务器,登录到mysql:

mysql -u root -p

• 修改密码:

尝试使用如下语句来修改

set password for 用户名@yourhost = password('新密码');

结果报错;查询得知是最新版本更改了语法,需用

alter user 'root'@'localhost' identified by 'yourpassword';

成功~

但在navicat里,原连接依然有效,而输入最新的密码,反倒是失败

打码部分为本机ip

在服务器执行

-- 查询所有用户

select user from mysql.user;

再执行

select host,user,authentication_string from mysql.user;

user及其后的host组合在一起,才构成一个唯一标识;故而在user表中,可以存在同名的root

使用

alter user 'root'@'%' identified by 'xxxxxx';

注意主机此处应为%

再使用

select host,user,authentication_string from mysql.user;

发现 "root@%" 对应的authentication_string已发生改变;

在navicat中旧密码已失效,需用最新密码才可登录

参考:

mysql 5.7 修改用户密码

关于修改账号,可参考此

这不是第一次遭遇"比特币勒索",在四月份,收到了这么一封邮件:

后来证明这是唬人的假消息,但还是让我学小扎,把Mac的摄像头覆盖了起来..