webee 最近的时间轴更新
test
2014-09-08 16:37:29 +08:00
webee

webee

V2EX 第 27033 号会员,加入于 2012-09-21 19:38:08 +08:00
1 G 17 S 37 B
webee 最近回复了
2020-08-19 09:53:37 +08:00
回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具
@nzbin 是挺清新的😂
2020-08-19 09:51:49 +08:00
回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具
@shoa dlx 是 solver 的算法,我这里是简单的回溯,后面会试试 DLX 。分步解法是实现的大家总结的一些逻辑推理技巧。其实学数独的时候会学习这些技巧,这个工具可以帮助学习和理解技巧。我写到一半发现其实挺多这样的工具的,我就尽量把技巧展现的更好理解。
2020-08-19 09:17:51 +08:00
回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具
@mara1 这个是个工具,并没有数独生成器。主要是辅助或学习使用各种技巧解数独,后面考虑加上。
2019-08-17 23:50:45 +08:00
回复了 iamdaguduizhang 创建的主题 问与答 三门问题
3 楼计算是正确的。
也可以换的方式思考:
P(不换选中概率)=P(3 选 1 选中概率)=1/3

由于主持人在剩余 2 个中排除掉一个
P(换选中概率)=P(3 选 2 选中概率)*P(1 选 1 选中概率)=2/3*1=2/3

推广到 n 个则是:
P(不换选中概率)=1/n
P(换选中概率)=(n-1)/n*1/(n-2)=(n-1)/n/(n-2)

n>=3 时,P(换选中概率)>P(不换选中概率)
2019-07-05 13:42:55 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker 就拿发一个 mq 消息到接收,这其中至少用到两次 rpc 调用( 4 次消息传递)了吧。再加上回复,一共四次 rpc 调用( 8 次消息传递)了吧。
你要的负载均衡是以增加至少 3 次 rpc 为代价换取的。

你据说的这种主动式负载均衡确实需要一个协调器的角色,在这里你使用了消息队列。但是在现存的任务负载均衡中也可以容易实现啊,只要增加 server 端和负载均衡的主动通信就可以了。

另外,服务器认为自己空闲,不代表它处理得就更快,也就不一定能降低平均延迟。
在现实情况下,主动式负载均衡除了增加系统交互复杂度,好像不比其他的负载均衡策略更好。
2019-07-05 13:01:12 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
看来楼主没明白一个问题,没有最好的技术,只有适合的技术,一切对比都是要有基准的。如果你觉得这么做在你的项目中合适且满足需求,那我觉得就没问题,至于是不是比其他人的方案更好就不一定了,这都取决于自己的认知水平。
2019-07-05 12:41:37 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker 你据说的 100%成功不是对所有消息都有意义,消息也是有时效性的,过了时间就没有意义了,因此才有超时的概念,所以 rpc 请求堆积然后处理不即时丢失很正常啊。
2019-07-05 12:33:03 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker 消息队列和 rpc 是两种不同的通信模式,消息队列是 publish/subscribe 模式,rpc 是 request/reply 模式,我们不说同步、异步的问题,很明显消息队列是单向通信,rpc 是双向通信,所以只要有单身通信能力就可以实现队列,有双向通信能力就可以实现 rpc,因此当然你搞两个消息队列就可以实现 rpc 是没有问题的。但是所有功能实现都是有其目的和衡量指标的,就 rpc 来说,主要目的是实现计算的扩展,把本地方法调用扩展到远程、分布式方法调用,计算需要逻辑(必要使用同步保证)和速度,因此 rpc 有两个指标:响应时间(延迟)和吞吐率( client 端和 server 端),且响应时间是更重要的,毕竟吞吐率是很容易通过扩展提升的。你的想法就是在直连 rpc 的中间加上一个队列,把 brokerless 的 rpc 变成了 brokered。在 client 端和 server 端条件不变的情况下,可能增加了 client 端的吞吐率(为什么是可能,因为 rpc 的 server 端也是有缓冲队列的啊),server 端吞吐率就算不变吧(不可能变得更好),整体响应时间肯定变长了,所以这个改变有什么意义呢?要实现你所说的优点完全可以在 client 端和 server 端做改进,没必要添加中间层啊?
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3127 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 14ms · UTC 13:53 · PVG 21:53 · LAX 05:53 · JFK 08:53
Developed with CodeLauncher
♥ Do have faith in what you're doing.