基于Nuxtjs、Vuejs、Express与Mongodb的多币种应用数据结构选型咨询

两个方案的核心优劣势对比 #

方案1：全币种定价预存储 #

• 优势：
  • 查询速度快，无需实时计算，接口响应性能更高
  • 支持自定义不同币种的定价策略，比如部分地区做专属折扣、定价取整调整，避免汇率换算后出现奇怪的小数，符合当地消费习惯
  • 汇率波动不会影响已上架产品的定价，不会出现用户前一天看到的价格第二天因为汇率变动产生涨跌的情况，有效降低客诉风险
• 劣势：
  • 新增币种时需要批量更新所有产品的定价，维护成本高
  • 产品文档体积会随支持币种数量上升而变大，如果支持几十种以上币种会产生明显的存储冗余
  • 每次产品调价需要同步更新所有币种的价格，操作复杂度高

方案2：基准货币+实时汇率换算 #

• 优势：
  • 数据结构简单，产品定价维护成本低，新增币种只需要更新汇率集合，不需要改动产品数据
  • 存储冗余极低，只需要存一份基准价+汇率表即可
  • 汇率可实时同步，定价跟随国际汇率自动调整，不需要人工干预
• 劣势：
  • 汇率波动会直接影响前端展示价格，旅游类产品客单价高，容易出现用户下单时价格变动的情况，引发交易纠纷
  • 无法针对不同币种做定制化定价，部分低汇率地区换算后可能出现不符合当地消费习惯的定价金额
  • 查询时需要多关联一次汇率表，大流量下会增加数据库查询压力，换算计算也会带来少量性能损耗

旅游类应用的最优选型建议 #

旅游产品属于低频次、高客单价、定价调整频率低的品类，更推荐采用混合方案，兼顾灵活性和稳定性：

1. 产品文档同时存储基准价（美元）和常用币种的预定义定价，非常用币种走实时汇率换算
2. 汇率表设置缓存，比如用Redis缓存最新汇率，1小时更新一次即可，不需要每次查询都读MongoDB的汇率集合，降低性能损耗
3. 下单时统一以当时的定价/换算价格做快照存储到订单里，避免后续汇率变动导致订单金额和支付金额不一致

MongoDB 实现参考 #

产品集合字段示例：

{
  "product_id": "xxx",
  "name": "东京一日游",
  "base_price": 100, // 美元基准价
  "custom_prices": {
    "CNY": 680, // 预定义的人民币定价
    "JPY": 14000, // 预定义的日元定价
    "KRW": 130000 // 预定义的韩元定价
  }
  // 其他产品字段
}

汇率集合字段示例：

{
  "currency": "SGD",
  "rate": 1.35, // 1美元兑换1.35新加坡元
  "updated_at": "2024-05-20T12:00:00Z"
}

内容的提问来源于stack exchange，提问作者imthegrv