# 位面世界

基本设定大纲

打开新世界的大门




## 背景设定

## 核心概念

不要你遵守规则，而是你创造规则

不要你探索历史，而是你创造历史

不要你遵循世界，而是你创造世界

### 基本概念

- 游人

各个位面出来的人形智慧生物，经常为了生成效力于各个不同位面不同势力，也有自由组件雇佣兵组织和商贸组织的存在

- 蓝星游人

高等游人，其智力水平极高，但人员十分稀有，据说来自蓝星位面的某个组织，喜爱互相争夺，经常挑起战争的位面战争的罪魁祸首，当然也有着爱好和平的蓝星游人，它们扎根于各个稳定的位面空间种田造访，吸引许多游人前往居住

- 位面中枢

思维具现化的载体，负责控制位面躯体操作

- 位面躯体

不同位面躯体都有所不同，蓝星位面常用的是人形位面躯体，仿造蓝星碳基智慧生物所打造

- 位面晶石

混沌中自然生长的晶石，其主要成份为各种能量元素的极限压缩体，位面空间诞生也来源于位面晶石大规模的膨胀坍缩时释放的巨大能量

- 位面空间

相当于巨大的位面晶石，其诞生于大规模的位面晶石无数次坍缩膨胀而产生，每个空间大小不一，生命周期不一，存在的资源也有限，而在空间形成后其内部也有可能会自然演化诞生孕育各种生命体和文明聚集地，在一个位面中空间的数量如同浩瀚海洋无穷无尽

### 建筑 · 地标

- 位面传送门

前往位面的唯一通道，坐落于特别行动队总部空间，由蓝星位面特别行动队负责把守监管，但其能源却是由A86商盟负责提供，玩家前往不同位面探索的主要任务之一就是找寻能维持位面传送门运转的资源

- 蓝星位面特别行动队总部空间

坐标代码为0021，其本身不存在于蓝星，所有招募的人员都是通过网络数据包进行中枢大脑塑造和位面人形打造前往，现实中肉眼并不可见，其空间主要也是由A86商盟所开辟，目前空间坍缩值为80，其维持稳定80%能量资源由A86商盟提供仅有20%是行动队自身资源所提供

- A86商盟地堡

A86商盟地堡不存在于任何一个空间，整体是由人力强行所开辟的空间，停留在自然空间之间的混沌缝隙中无坐标可言，目前没有人能主动找到该地堡，只有A86商盟人员带领人进入


### 组织

- 蓝星位面特别行动队

自从掌握跨越位面技术后蓝星联合秘密创立的组织，主要负责招募培训人员前往未知位面建立基地获取资源后传回蓝星所用，但去往其他位面后能返回的人寥寥无几，因此风险极大人员也难以招募。主要技术装备来源严重依赖A86商盟，因此摆脱对A86商盟的依赖也是蓝星位面特别行动队主要任务

- 蓝星A86商盟

有传闻称该商盟创始人并非蓝星位面的人，而是从其他位面高级文明而来的人所创立，其成员安全往返各个位面的几率极大，其人员装备技术先进且是蓝星位面特别行动队的指定供应商，神奇的是据各个位面回来的人说它们都曾在各个陌生的位面都看到过该商盟的存在，蓝星位面特别行动队也受制于A86商盟，因实力差距较大且商盟表现态度友好，至少暂时平安无事



## 台词

### NPC邀请函


- 刘宁


“你好，我是蓝星位面特别行动队A86代理人，我叫刘宁，前不久我们组织在某一个位面遭受了重大损失，现急缺人手，现在想邀请你加入我们，我们的任务主要是负责探索位面世界，有一定风险但同时也能让你打开新世界的大门，希望你能考虑一下。 切记，不要向任何人透露此条消息”

- 刘大头


“喂喂喂，哎，你好啊，我是蓝星位面特别行动队A86三组组长刘大头，最近咱们缺人，咱们主要负责跨越位面冒险探索，建立基地搜索资源并回传资源给地球总部，喔，有点小风险但问题不大，你要加入吗？ 对了，消息不要告诉别人喔”

- 毛弟


“咳咳，你好啊，幸运儿，你获得了一个跨越位面旅行的机会，我叫毛弟，我隶属于蓝星位面的A86商盟，咱们商盟专门负责蓝星位面特别行动队提供资源，最近有点缺人，这条消息是给你一个加入我们的机会，”

- 宁骑

“废话不多说，简而言这条消息就是告诉你要不要加入我们，对了，我们是蓝星位面特别行动队，不知道也没关系，加不加入就完事了，加入后你自然会知道一切”

### 场景加载词

“正在打造位面人形躯体...”

“正在植入位面中枢大脑...”

## 等级设定

等级 ： 甲(jiǎ)、乙(yǐ)、丙(bǐng)、丁(dīng) 戊(wù)、己(jǐ)、庚(gēng)、辛(xīn)、壬(rén)、癸(guǐ) 
对应权重：10-1

## 资源获取方式

除基础资源，所有资源当前都是由置换水晶提供


## 计算公式

### 种植机制

最终收获数量 = 收获产量* (实际种植时间/生长周期) + 湿度 + 营养含量

### 战斗机制

权重 =人员属性buff总合 + 护甲buff总合 +武器buff总合

战力权重 = 权重*人员数量

战斗算法：根据双方权重进行随机选取，随机后成功的即胜利一方

位面-基本设定

使用 RequireClaim 方法来要求用户的 userType 声明必须为 "system"，即只有带有 "system" 用户类型声明的用户才能访问该授权策略




# JWT授权备忘

- 生成token

> 注意演示用的 Claim

```c#
public string GenerateJwtToken(string userId, string userType)
{
    var claims = new List<Claim>
    {
        new Claim("userId", userId),
        new Claim("userType", userType)
    };

    var key = new SymmetricSecurityKey(Encoding.UTF8.GetBytes("your_secret_key"));
    var credentials = new SigningCredentials(key, SecurityAlgorithms.HmacSha256);

    var token = new JwtSecurityToken(
        claims: claims,
        expires: DateTime.UtcNow.AddHours(1),
        signingCredentials: credentials
    );

    return new JwtSecurityTokenHandler().WriteToken(token);
}
```
产生token

```
var systemUserToken = GenerateJwtToken(systemUserId, "system");
var regularUserToken = GenerateJwtToken(regularUserId, "regular");
``` 离开了一线自己创业，有些东西会随着时间的推移遗忘，避免用到的时候发挥时间找资料，弄个白痴都能看懂的备忘录


- 接口定义授权策略

`  [Authorize(Policy = "SystemUserOnly")] `


- 配置

```c#
public void ConfigureServices(IServiceCollection services)
{
    // 添加授权策略
    services.AddAuthorization(options =>
    {
        options.AddPolicy("SystemUserOnly", policy =>
        {
            policy.RequireClaim("userType", "system");
        });
    });

    // 其他服务配置...
}

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    // 其他中间件配置...

    // 添加身份验证和授权中间件
    app.UseAuthentication();
    app.UseAuthorization();

    // 其他路由配置...
}
```

.Net 知识备忘

客户资料


- [主要参考文档](https://github.com/milvus-io/bootcamp/tree/master/applications/image/reverse_image_search)
- [主要使用的向量搜索引擎Milvus](https://milvus.io/)

## 主要对接

> 我们需要对接的部分其实就只有 webserver，也就是重写调整构建 milvusbootcamp/img-search-server:2.2.10 这个镜像的内容

- [2.2版本源代码地址](https://github.com/milvus-io/bootcamp/blob/v2.2.10/solutions/image/reverse_image_search/server/Dockerfile)
- [主分之源码地址](https://github.com/milvus-io/bootcamp/blob/master/applications/image/reverse_image_search/server/Dockerfile)
- [代码备份地址](https://github.com/NingLiu1998/milvus-python-demo)





docker-compose 文件

```yaml

version: '3.5'

services:
  etcd:
    container_name: milvus-etcd
    image: quay.io/coreos/etcd:v3.5.5
    networks:
      app_net:
    environment:
      - ETCD_AUTO_COMPACTION_MODE=revision
      - ETCD_AUTO_COMPACTION_RETENTION=1000
      - ETCD_QUOTA_BACKEND_BYTES=4294967296
      - ETCD_SNAPSHOT_COUNT=50000
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/etcd:/etcd
    command: etcd -advertise-client-urls=http://127.0.0.1:2379 -listen-client-urls http://0.0.0.0:2379 --data-dir /etcd

  minio:
    container_name: milvus-minio
    image: minio/minio:RELEASE.2023-03-20T20-16-18Z
    networks:
      app_net:
    environment:
      MINIO_ACCESS_KEY: minioadmin
      MINIO_SECRET_KEY: minioadmin
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/minio:/minio_data
    command: minio server /minio_data
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9000/minio/health/live"]
      interval: 30s
      timeout: 20s
      retries: 3

  standalone:
    container_name: milvus-standalone
    image: milvusdb/milvus:v2.2.10
    networks:
      app_net:
        ipv4_address: 172.16.238.10
    command: ["milvus", "run", "standalone"]
    environment:
      ETCD_ENDPOINTS: etcd:2379
      MINIO_ADDRESS: minio:9000
    volumes:
      - ${DOCKER_VOLUME_DIRECTORY:-.}/volumes/milvus:/var/lib/milvus
    ports:
      - "19530:19530"
      - "9091:9091"
    depends_on:
      - "etcd"
      - "minio"

  mysql:
    container_name: img-search-mysql
    image: mysql:5.7
    networks:
      app_net:
        ipv4_address: 172.16.238.11
    environment:
      - MYSQL_ROOT_PASSWORD=123456
    ports:
      - "3306:3306"

  webserver:
    container_name: img-search-webserver
    image: milvusbootcamp/img-search-server:2.2.10
    networks:
      app_net:
        ipv4_address: 172.16.238.12
    environment:
      MILVUS_HOST: '172.16.238.10'
      MYSQL_HOST: '172.16.238.11'
    volumes:
      - ./data:/data
    restart: always
    depends_on:
      - standalone
      - mysql
    ports:
      - "5000:5000"

  webclient:
    container_name: img-search-webclient
    image: milvusbootcamp/img-search-client:2.2.10
    networks:
      app_net:
        ipv4_address: 172.16.238.13
    environment:
      API_URL: 'http://127.0.0.1:5000'
    ports:
      - "8001:80"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://127.0.0.1:8001"]
      interval: 30s
      timeout: 20s
      retries: 3

networks:
  app_net:
    driver: bridge
    ipam:
      driver: default
      config:
        - subnet: 172.16.238.0/24
          gateway: 172.16.238.1


```

以图搜图搭建

进来准备重新找工作面试，顺便梳理一下自己过往的经验总结...

本人理论词汇掌握不多，大多数时候都会讲人话





# 场景描述

1.用户下单，商品库存已经不足了，但还是扣减了

2.医生开方，药品不足了，但还是被开了出去

··· 类似场景

# 解决思路

## 思路1：预扣库存

用户下单时，系统先进行预扣库存操作，然后后将“下单业务”发布到MQ(消息队列）进行处理，成功通知，失败回滚预扣库存操作

- 对于预扣库存时可能出现的“超卖”现象，可以采用针对数据库表的悲观/乐观锁，具体用哪种，看场景，下文有讲

## 思路2：异步通知

用户下单时，直接提交，后台丢入MQ，然后进行业务处理，前端直接提示操作完成

- 这个处理方式，极大的提升吞吐量，因为不需要“即刻”处理，后续获取结果方式则可通过各种方式来通知，如微信公众的消息订阅模板消息，短信、邮件，等。
- 这个场景在BAT产品中可以找到相关例子，例如早期微信充值手机花费的早期处理思路，就是提示“充值操作完成，具体结果稍后通知” （现在已经改了，页面等待即会通知）

## 悲观/乐观锁 使用场景

### 基本概念

#### 悲观
阻塞（等待），超时报错

- 假设会冲突，好处是能保持数据一致性，设计思想是不管咋样先无脑上锁
，说人话就是“**我每次出门都先带一瓶防狼喷雾，不管我会不会遇到危险情况，我假设可能我被坏蛋盯上了**”显而易见，这样我出门花费的时间成本肯定增加了，代码层面就是耗费的性能增加了

#### 乐观
假设不冲突，提交更新对比版本号，失败报错，设计思想就是是尽量减少锁的使用

- 说人话就是“**出门不带防狼喷雾了，我觉得世界坏蛋不多**”

- 高并发的修改操作，乐观会频繁更新冲突报错，如果你逻辑写了重试操作，那么久一直报错重试N循环，这时候已经不适用乐观，应该使用悲观

### 结合场景

- 用户下单，医生开方，规模到达一定量时，肯定要保证不要出现“超卖”现象，因此扣减库存使用悲观无可厚非
- 其他场景，如基础字典数据维护，用户修改个人信息，扣减用户余额等一系列操作，一般稳妥期间都会加上乐观锁，其场景就是并发量并不大


### 实际代码应用

这种锁机制，不管你用什么基本都很成熟了

针对数据库，我这里推荐的[sqlsugar](https://www.donet5.com/home/doc?masterId=1&typeId=2399)这个ORM，使用sqlsugar能够很容易的针对数据库表进行乐观/悲观锁的操作，其稳定和成熟性也经过了多年多家大头公司认可了,使用方法看[官方文档](https://www.donet5.com/home/doc?masterId=1&typeId=2399)很详细

如果是分布式锁，这里推荐的是[FreeRedis](https://freesql.net/guide/freeredis.html)它里面有基于redis封装好了分布式锁的使用，调用十分简便，我个人实际公司业务上也是使用了这个


# 为了解决A问题二又带来的B问题解决方案

## 引子：

通过上诉解决方案后，**理论上技术层面性能问题**顶住没啥问题了

~~（这如果还有问题，想必你司业务及其牛X，更进阶的方案也没啥实际上的技术思路提升，无非就是把处理业务的模块继续拆分，拆分后的各个粒度更小的业务服务再加大规模的集群，也就是现在大厂普遍的微服务）~~

但是可能会有一个新的问题，例如：A客户看中一个热门商品满心期待的去下单，下单完心里美滋滋幻想着用上这个商品然后去睡觉，第二天起来才看到 “对不起，下单失败，库存不足”，直接各种恶毒的语言开始诅咒开发这个产品的人

在**某些业务场景下**这种情况是允许的，而在某些产品上，这种情况则是不被允许存在的，实际解决其实也简单，如果项目有ws，可以考虑**在页面等待ws获取结果，如果没有则轮询请求某个api返回最终结果**

有没有发现，我本来 “**普通一个接口搞定的事情，现在为了解决‘可能存在的’问题要做的事情反而多了**”所以具体公司业务开发的时候，更多的是要掌握好实际需求以及实际预估场景，一句话自己根据实际场景把握好，“编程永远没有万金油”



:::danger{title="温馨提示"}
这就是现如今利用各类技术解决问题后，衍生出来的新问题，因此请实实在在的确保你的项目实际上存在这么大的流量和高并发，真真切切存在此类问题需要解决，才考虑这些技术手段的解决方案，千万不要成为段子中的：“技术上异步填谷削锋，运行时用户白天20晚上15”  我经常提醒自己，“不要为了写代码而写代码”
:::