mourner

@poembre #3

在拍卖行这里需要使用 redis 进行数据的交互, mysql 仅纪录未来,或者当前设计需求中要满足的数据储存.

使用 Elasticsearch 储存交易纪录就好, 实际的交易内容对于整个拍卖系统来说并没有任何意义.

例如,张三有 10000 把属性不同的太刀 , 他以不同的价格上架到太刀分类中, 那么在拍卖行中你数据中储存的就是 10000 把太刀的交易信息, 但是随着被人购买,物品正常发往购买者的库存中, 那么交易信息的 redis 数据就可以直接删掉这件道具的售卖相关信息. 只需要把详细的交易纪录储存到 Elasticsearch 中方便数据查询就好.

在我的认知里, mysql 应该是不能完成这样的高频读写更新功能.(体量比较的话可以.)

DNF 的交易系统使用体验简直一坨屎.

我觉得如果实现 DNF 的交易功能,一般来说可以使用 redis + mysql 的方式.
redis 提供基础的查询购买等需求, mysql 做持久化储存使用(方便统计图表数据记录使用).

首先是用户的浏览商品页面,这个页面需要作出快速响应,展示出所有物品,这一层仅需要分页展示商品列表,具体的交易信息最好还是再分层进入查询.道具的具体目录最多几万种道具,所以查询目录速度会非常快.(这一层可以模糊查询道具,然后给出列表)

然后是用户的购买页面,当用户进入道具售卖界面时,列出当前道具的售卖商品信息.

其他的业务同理, 最多在购买和上架时要处理业务逻辑判断保证购买的有效性.

思路就是像这样拆分业务,具体内容具体处理. 感觉你用四个表来操作拍卖行,那你会比 dnf 拍卖行还要卡.

挺离谱的,
如果你全家人的生活是依靠你岳父母家的话,那给个冠名权没问题.
试想把这种情况换做你岳母家的儿子她们同意吗?
头胎跟了岳父母家姓氏,基本上就代表了在你跟你对象的婚姻上,岳父岳母才有话语权.
如果真实情况就是岳父母家占经济主导地位的话,跟谁姓也就无所谓了.
感觉未来的生活还很长,如果这种事情上都要压你家一头的话,感觉这也太难相处了.

我觉得可以一起看看试试,
看看她喜欢的内容到底是什么,
在某些时候要引导正确的理解方式,
可能小孩现在对于外界的认知就是看短视频.

现在的需求没必要上 990pro,
两年前我 980pro 买的 4k,现在好像只要 1.5k.
如果你全套组装机器的话全买最好的就行,
现在这个情况,随便买个差不多的硬盘先用着就好.

我的建议是收费并且在 v 站免费发放用户码.

现在社会默认是不需要的, 如果特殊岗位的话应该在入职前会有说明.

如果有公司会卷到这个地步, 看看能不能招到员工就好(工资高可以福利好或许可以).

现在在用 gpw2

骑驴又不妨碍你找骂.