V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  webee  ›  全部回复第 1 页 / 共 1 页
回复总数  19
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(不换选中概率)
一个 slice 值是对底层数组的一个固定切片,长度是不可变的,每次改变长度都是生成新的切片。
%p 对于 slice 来说返回的是底层数组的地址,真实的 slice 值的地址需要取地址符&。
2019-07-05 13:42:55 +08:00
回复了 springmarker 创建的主题 程序员 在微服务中是用队列好还是 RPC 好
@springmarker 就拿发一个 mq 消息到接收,这其中至少用到两次 rpc 调用( 4 次消息传递)了吧。再加上回复,一共四次 rpc 调用( 8 次消息传递)了吧。
你要的负载均衡是以增加至少 3 次 rpc 为代价换取的。

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

另外,服务器认为自己空闲,不代表它处理得就更快,也就不一定能降低平均延迟。
在现实情况下,主动式负载均衡除了增加系统交互复杂度,好像不比其他的负载均衡策略更好。
2019-07-05 13:08:01 +08:00
回复了 ooToo 创建的主题 Go 编程语言 golang for loop 中的 gocoroutine 的问题
i 只初始化一次,作用域是 for 这个 block.
且 go routine 在大多数情况下遇到阻塞时都会放弃执行,所以 for loop 结束时,那些新起的 go routine 才开始被调度。
这种情况下可以通过加参数或者在 for loop block 中新建变量来解决,这叫捕获循环变量。
在使用 ide 的时候,go vet 会对这种情况有提示。
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 端做改进,没必要添加中间层啊?
2019-07-04 15:34:40 +08:00
回复了 webee 创建的主题 分享创造 关于复杂网站的前端并行爬取方式
@silencefent 不好意思,仔细了解了一下,流量宝,确实也是共享的思想。。
2019-07-04 15:31:19 +08:00
回复了 webee 创建的主题 分享创造 关于复杂网站的前端并行爬取方式
@silencefent 流量宝还是使用自己的的服务器来做刷流量的事情,其实我想的是真实用户共享合作来分享算力和流量,和众包是一个意思。
2019-07-03 18:00:45 +08:00
回复了 webee 创建的主题 分享创造 关于复杂网站的前端并行爬取方式
@ho121 这里主要不是代理的问题,如果能简单的在后端爬取,代理当然可行。
这里的问题是对于复杂的不那么好爬取的网站使用前端爬取,解决各种后端爬取的痛点,同时实现资源共享。
2018-01-11 23:37:42 +08:00
回复了 junwuhui 创建的主题 全球工单系统 github 挂了
好了。
2018-01-11 23:36:24 +08:00
回复了 junwuhui 创建的主题 全球工单系统 github 挂了
发现挂了,就来 V2EX 了。
2017-03-31 19:30:56 +08:00
回复了 ijiami 创建的主题 推广 程序员,你亮了!(有福利,手慢无)
open
2017-01-16 20:35:45 +08:00
回复了 iugo 创建的主题 数据库 两个对立的同类型数据(如收入和支出)如何储存才最优?
改正一下,是关联概念
2017-01-16 20:34:53 +08:00
回复了 iugo 创建的主题 数据库 两个对立的同类型数据(如收入和支出)如何储存才最优?
例二,非负数,收入和支出对同一个人是独立的事件。例二则把二者当成了关键概念。而且例二做收入,支出,结余更自然啊。最后我认为这儿的收入,支出不是对立概念。
2012-10-09 23:28:32 +08:00
回复了 zhangxiao 创建的主题 程序员 大家放项目(工作的,自己的)的文件夹一般叫啥?
~/test:放各种代码,repo
~/null:做测试,+各种乱七八糟的。
哈哈
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2848 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 33ms · UTC 05:54 · PVG 13:54 · LAX 21:54 · JFK 00:54
Developed with CodeLauncher
♥ Do have faith in what you're doing.