webee 最近的时间轴更新 webee 最近的时间轴更新 test 2014 年 9 月 8 日
 | webeeV2EX 第 27033 号会员，加入于 2012-09-21 19:38:08 +08:001  17  37  |
webee
| 使用 react 写了个网页版数独工具 分享创造 webee 2020 年 8 月 19 日 最后回复来自 adminharlem | 7 |
| 关于复杂网站的前端并行爬取方式 分享创造 webee 2019 年 7 月 11 日 最后回复来自 yangweijie | 9 |
webee 最近回复了
2020 年 8 月 19 日 回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具 |
@nzbin 是挺清新的
2020 年 8 月 19 日 回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具 |
@shoa dlx 是 solver 的算法，我这里是简单的回溯，后面会试试 DLX 。分步解法是实现的大家总结的一些逻辑推理技巧。其实学数独的时候会学习这些技巧，这个工具可以帮助学习和理解技巧。我写到一半发现其实挺多这样的工具的，我就尽量把技巧展现的更好理解。
2020 年 8 月 19 日 回复了 webee 创建的主题 分享创造 使用 react 写了个网页版数独工具 |
@mara1 这个是个工具，并没有数独生成器。主要是辅助或学习使用各种技巧解数独，后面考虑加上。
2019 年 8 月 17 日 回复了 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(不换选中概率)
也可以换的方式思考：
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 年 7 月 5 日 回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好 |
@springmarker 就拿发一个 mq 消息到接收，这其中至少用到两次 rpc 调用（ 4 次消息传递）了吧。再加上回复，一共四次 rpc 调用（ 8 次消息传递）了吧。
你要的负载均衡是以增加至少 3 次 rpc 为代价换取的。
你据说的这种主动式负载均衡确实需要一个协调器的角色，在这里你使用了消息队列。但是在现存的任务负载均衡中也可以容易实现啊，只要增加 server 端和负载均衡的主动通信就可以了。
另外，服务器认为自己空闲，不代表它处理得就更快，也就不一定能降低平均延迟。
在现实情况下，主动式负载均衡除了增加系统交互复杂度，好像不比其他的负载均衡策略更好。
你要的负载均衡是以增加至少 3 次 rpc 为代价换取的。
你据说的这种主动式负载均衡确实需要一个协调器的角色，在这里你使用了消息队列。但是在现存的任务负载均衡中也可以容易实现啊，只要增加 server 端和负载均衡的主动通信就可以了。
另外，服务器认为自己空闲，不代表它处理得就更快，也就不一定能降低平均延迟。
在现实情况下，主动式负载均衡除了增加系统交互复杂度，好像不比其他的负载均衡策略更好。
2019 年 7 月 5 日 回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好 |
看来楼主没明白一个问题，没有最好的技术，只有适合的技术，一切对比都是要有基准的。如果你觉得这么做在你的项目中合适且满足需求，那我觉得就没问题，至于是不是比其他人的方案更好就不一定了，这都取决于自己的认知水平。
2019 年 7 月 5 日 回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好 |
@springmarker 你据说的 100%成功不是对所有消息都有意义，消息也是有时效性的，过了时间就没有意义了，因此才有超时的概念，所以 rpc 请求堆积然后处理不即时丢失很正常啊。
2019 年 7 月 5 日 回复了 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 端做改进，没必要添加中间层啊？
Select Language