客户资料


- [主要参考文档](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”  我经常提醒自己，“不要为了写代码而写代码”
:::

高并发处理

💕鸿蒙



2023年度挖坑浏览：

- [ ] 模仿禅道，简化功能，需求是符合小公司使用习惯
- [ ] 在线图片生成（除了生成图片，还生成C#生成图片的代码，场景是一些活动商品等海报图）
- [ ] 模仿sqlsugar的webfirst
- [ ] 私有网页收藏夹 （支持生成离线单Html页面）
- [ ] 小博客系统
- [ ] 论坛系统
- [ ] 
