cszhang

> > > 看起来很好看啊，一个小想法，上传图片，选择关键词，然后根据照片配词如何？ > > > > > > 你是说智能化吗？根据照片内容分析去匹配诗句吗？这个难度就比较大了，短期内做不出来 > > 请问有公开代码仓库吗？我研究过AI算法，可以提供支持 微软谷歌有相应的图片解析服务， 然后做个贝叶斯相关度匹配就好。

顶一下。我也是，怎么解决呢？

```python #from ... import StatusEnum class StatusEnum(enum.Enum): none ="none" ready="ready" runing="running" fail="fail" success="success" class Author(db.Model): __tablename__ = "authors" id = db.Column(db.Integer, primary_key=True) name = db.Column(db.String, nullable=False) status = db.Column( db.Enum(StatusEnum),default=StatusEnum.none)...

ok。了解了

> 感觉最后可以加一步，当余票很少时，也许把用户id本地hash，少于多少（比如还有10张票，QPS1w，用hash值少于多少卡掉99%的请求，使qps就100（为余票个数*10）就行）的直接返空，直接显示售罄了，这样让大部分本地库存不用再去请求redis远程减库存。 感觉可以，但是用IP太不公平了吧，不如只用session，然后随机选1%放行。

感谢您的回答，我明白您的意思，但我还有一点些疑惑： 1.对于服务端根据火车车次进行均衡，这肯定没问题。 2.但对于同一辆火车，分库减票和总Redis减票相对于订单生成是原子操作（但两次减操作的顺序我不太明白），且订单的成功是以总Redis减票成功作为标志的。 我又看了一遍ReadMe，目前我是理解的是2.1的情形，不知是否正确。 对于单个分库来说: 2.1 当客户端并发请求时，会先对这个分库进行票量减逻辑，筛选出成功的请求后再请求Redis减票逻辑，总Redis减票成功后，订单成功。这样就把压力分给了单个分库。 2.2 相反的例子是，客户端并发请求时，不会先对分库的票量进行减逻辑，仅仅根据分库票量判断是否充足，然后等到Redis减票成功后，再对分库进行减票逻辑，然后生成订单。如果是这样的话，相当于进行了一个先分后总，并发会集体转移到Redis。 ------------------ Original ------------------ From: "GuoZhaoran"

确实没什么意义了，应该是第一种。   ------------------ Original ------------------ From: "Yeongjet Tang"

I'm just starting to use it. Should I consider something else?