请稍等 ...
×

采纳答案成功!

向帮助你的同学说点啥吧!感谢那些助人为乐的人

一哥,麻烦回答一下你自己提的两个问题吧

回答1 浏览179 2020-10-11 23:53:08

如题,是一哥你自己提的问题哈哈。也是到目前为止,你提过的我印象很深的两个问题。

  1. 优惠券系统中使用的是提前生成的优惠券码,保证了编码不重复且编码有意义。
    你的问题是:如果是动态生成优惠券码的话应该如何实现呢?我在群里见过别人说的方式都是保证唯一性(UUID呀,雪花呀乱七八糟的)。但是都会丢失编码中可包含的意义。我感觉你字里行间的意思还是这两者可以兼顾的。
    一哥,你对这个问题的官方答案是什么呢?
  2. MySQL专栏中。分库分表那一块,说到user表按照user_id水平拆分后的查询问题。
    user 表拆分之后,如果我想用 user_name、email、phone 去查询用户信息,怎样做效率会高呢 (注意,数据分布在多个库、多个表中,轮询自然是不合理的)?
    我的问题是:怎么做效率会高呢(注意,数据分布在多个库、多个表中,轮询自然是不合理的)?
  3. 老勤,你休假了吗?

添加回答

已采纳回答

宇文老师你好:

    我不得不说,你这里提出的两个问题质量都非常的高,哦,不,是我自己提出的两个问题。当然了,能给宇文老师留下深刻的印象,我也是很欣慰的。我这里首先回复你的第三个问题:我近期大概率不会休假。

    第一个问题,如何动态的生成优惠券码,且不丢失编码中包含的意义。

    不错,这个问题问的非常好。我们先来辩证一下,分布式 id 生成算法可行吗?我认为:可行但不是最优解。可行的原因很简单,因为只要优惠券码是唯一的就可以了。但是,这样做无疑会丢失优惠券码中涵盖的业务意义。那么,怎么做呢?简而言之就是:区间分段。看以下的详细步骤说明:

    (1)我们首先需要一个注册中心,我们的服务都需要注册中心知晓

    (2)我们部署的每一个实例都会注册到注册中心,那么,注册中心就可以给每一个实例分配它所能分配的 id 区段,例如:A 实例分配 11 ~ 20,B 实例分配 21 ~ 30,等等依次类推,这样既可以保证优惠券码中包含有业务含义,也能够保证优惠券码是唯一的,且不会导致优惠券超发

    那么,问题来了,这样做,会有可能导致某个实例已经分配完了,而另外的实例还有优惠券分配的额度。这个问题其实很简单,也有两种处理策略去应对:

    (1)忽略这个问题,就是你有时候会看到的,明明看到 app 上显示还有余票,但是,点击购买的时候,告诉你已经销售光了,那么,其实就是直接忽略了。这不会有什么问题,只是你买不到了,而实际上肯定会有人能够成功购买(这就是传说中的看运气了)

    (2)因为各个实例有统一的注册中心,所以,你的实例可以转发到还有库存的实例上去,让其他的实例来生成优惠券码。但是,这样做,无疑会有很多工作量,例如:请求转发、实例生成优惠券码的记录等等。

    不过,这个系统仍然不够完善,动态生成优惠券的区间分段分配只是最理想的情况,但是,如果某个实例挂了,一部分优惠券码没有分配成功,就会导致库存不能被完全消耗。这还需要做补发相关的逻辑。等等类似的复杂问题还有很多,所以,我最终建议你:静态生成,至少我见过的优惠券系统都是静态生成的。


    第二个问题,这个问题其实很简单了,你说的是有道理的,当然是可以根据 username、email、phone 去查询用户信息。最好的办法就是索引,即建立索引表。这里可以建立三张索引表:

    (1)user_id、username 构成一张表

    (2)user_id、email 构成一张表

    (3)user_id、phone 构成一张表

    即使你有十亿条数据,这么简单的表结构查询都是非常快的,且存储也是最小的消耗。我相信宇文老师应该理解老勤的意思啦!


    我是勤一,致力于将这门课程的问答区打造为 Java 知识体系知识库,Java 知识体系 BBS!共同建造、维护这门课程,我需要每一个你!

2020-10-12 11:01:48

Java实操避坑指南 SpringBoot/MySQL/Redis常见错误详解

难度中级
时长22小时30分钟
人数238
好评度100%

掌握业务开发中各种类型的坑,纠正常见误区,Java web开发领域通用

讲师

老勤 JAVA开发工程师

高级技术专家,曾就职于微软、腾讯,目前就职于知名电商互联网公司,拥有丰富的大型项目开发经验。多年IT从业经验,一线软件设计、研发,熟悉C、CPP、Java等开发语言,对Web框架、数据存储、架构设计等有深入的理解和实践。

意见反馈 帮助中心 APP下载
官方微信