南京, 今天不行了, 呜呜呜...

@l9rw cww ?

用 v2ray 吧, ssr 没啥人维护了吧..

@meeop 可以看看附言

@meeop 客户端有重连机制, 就是现在不会很快重连, (太快重连怕服务器顶不住哇)
Socket 实现的比较简陋, 就是单机, 然后走网关连过来, 多机不知道咋整太菜这不是来问了

@MoYi123 很酷

@licoycn 对哦, 这样感觉不错, 实现也比较简单

@THESDZ Socket 状态存到外部, 多个实例共享这些状态吗?
emm.... 我有点查不到什么资料.

有无一些推荐的 Demo 之类的开源项目做到了这些呢?

@licoycn 就是让客户端断了, 能够快速的自动重连就好? (我现在的业务中断个 1 -2 分钟可能就客户会叫了, 直接重启现在只敢晚上搞, 大概中断 1 分钟)

如 @THESDZ 所说 实现环形 hash
A 节点挂了, 赶紧重连到 B 节点, A 重启后再重启 B, 所有客户端重连到 A. 这样感觉问题也不大 (可能中断在加起来几秒?)

2020 3.1 感觉良好

@unclemcz 不管在那里都输入车牌缴费反而没什么问题, 但是有的人就是喜欢在杆子底下缴费出去 , 操作的还慢, 会导致出口堵.

现在其实两种方式都提供, 你可扫场内码预交费, 也可到出口免输入车牌直接缴费,

问题出在免输入车牌直接缴费这里, 有年龄大的人, 认为扫了就能缴费什么都不管...
抢缴费这个问题其实是越来越少的 (码的位置调整让后车更难扫, 知道不能扫前车的人越来越多....)
可能后面更少了, 也会转成自动退款模式, 或者每个停车场可配的可选自动退款或手动退款

@Jtyczc 同一个车牌付了两次费 , 再次拍本来就是对的,
并且车子拱到杆子底下的时候, 现在的主流方式其实已经拍不到车牌了 刚才 @错了

@unclemcz 见楼上

@Jtyczc
其实 3 种都有用到,

是很难错, 但是总有些奇葩的人

第一二种其实是差不多的
"第一种需要排队" 后面的人真的会在前车还没出场时就扫码, 还有就是主驾驶和副驾驶同时抢着缴费的

"液晶屏幕展示可变二维码, 强光下或者太小会有很多扫不出来的", 很多地方出口也会贴固定码,

可以总结下: 后面的人真的会在前车还没出场时就扫码, 这个偶尔真有人干

是很难支付错误, 但是量大了 就是有人抢别人的码, 就是有人不看车的照片和车牌, 直接缴费....

@unclemcz 是 trade_no 和 order_id 形式,

单人多次付款自动退款是没啥问题

同时两个人付款, 总是会存在一个钱退给谁的问题. 如果不管是退给谁都无所谓那就自动退款也没啥问题,

同时两个人付款 如果只能退给错缴的人, 自动退款就 "失灵" 了, 如何判断谁才是错缴的? 感觉简直无解

这个场景其实就是汽车缴费出场, 扫码直接付款
错缴费的人 A 实际需要缴费的人 B, A 和 B 同时缴 B 的车牌的费用

先收到了 A 的回调, B 的回调比较晚, 然后如果退了 B 的, A 就会投诉过来(A, B 互相不认识没有关系),
因为 B 相当没有收费逃单了, A 缴纳了 B 的钱, 自己的又要付.

电商那种思路的话之间退掉多付的就好了没啥问题,不存在一个 trade_no 退掉了多缴费的还有啥纠纷, 一般没有陌生人帮你付订单的, 并且就算给你退错款了, 也可以取消订单不给你发货这种手段

汽车缴费到业务结束流程太快了, 最快的话付完钱 10 秒内就溜了, 退错了就没有什么补救手段都没有了,

多次支付无法规避

楼上说的自动退款也是个办法!

但是我这里自动退款也不行,是扫码缴费, 存在错缴费的人先缴费的情况, 自动退款可能退错.

目前是手动等客户联系退款的, 页面上各种提示和信息展示, 实际场景优化, 还是有人两个人客气抢着缴费同时缴纳, 或者排队的时候后面的人错缴前面人的, 现在的多次缴费比例大概是 10 万分之一吧, 勉强接受

尝试过 RESTFull, 但是没有完全遵守起来, 现在个人的实践,
http code 500 服务器真的内部错误.
http code 401 未授权
http code 200 (业务 code 400 是密码错误这种), 就是业务上的错误,我认为是成功的, 让让前端会有个统一的拦截器去处理业务 code

原则就是 http code 必须保证符合原有的意思, 200 里面再加上业务 code,
但是像是未授权这种, 可能既是业务错误, 也可以理解为 http code 错误 就很头疼

RESTFull 我遇到的问题(Java):
1. 有些内网的防火墙不允许 delete 这种请求进去.. 很让人无语
2. RESTFull 一个 URL 可能对应多个接口, 按照路径配置各种规则的时候 , 日志打印, 就打地址的话看不出调用是那个具体接口, 解决其实也能解决, 日志加上请求的方式, 规则按请求方式 + URL 去配置.
3. 就是理解不明确的, 不知道定义为那种方式的接口
4. Get 传大量查询参数, 不方便的接口, 前端意见很大, 后端接收也不是很方便, 偷懒用 Post 了不少

我觉得 Get 传参限制太多了, 通常只能携带路径参数 (其实理论上服务器也能接收 Get 请求体), 要是能加一种查询的
类似 Get + 能发请求体就好了, 其他的问题都是可以解决,最多麻烦点, 慢慢都会好

@cpstar
是的, 这个卡比较低端, 但是显存有 4G, 渲染方式的不同 结果会体现在 GPU 核心的使用占用率上吧?