webee 最近的时间轴更新 webee 最近的时间轴更新
test
2014-09-08 16:37:29 +08:00
webee's repos on GitHub
Java · 0 人关注
android-chat-ui
Android Chat UI library.
Python · 0 人关注
apistar
A smart Web API framework, designed for Python 3. 🌟
Java · 0 人关注
AppRTCDemo
Android AppRTC Demo of WebRTC project
0 人关注
autotester
Chrome extension that allows to develop and run automation tests right in browser
0 人关注
awesome
😎 Awesome lists about all kinds of interesting topics
0 人关注
awesome-AI-books
Some awesome AI related books and pdfs for learning
Ruby · 0 人关注
awesome-react-native
An "awesome" type curated list of React Native components, news, tools, and learning material
0 人关注
bash
a bunch of bash helper functions
HTML · 0 人关注
book-warehouse
My Book
0 人关注
books
【编程随想】收藏的电子书清单（多个学科，含下载链接）
Python · 0 人关注
boom
A replacement for AB (Apache Bench)
0 人关注
bromite
Bromite a Chromium fork with ad blocking and privacy enhancements; take back your browser!
0 人关注
browser-fingerprinting
Analysis of Bot Protection systems with available countermeasures 🚿. How to defeat anti-bot system 👻 and get around browser fingerprinting scripts 🕵️♂️ when scraping the web?
0 人关注
C4-PlantUML
C4-PlantUML combines the benefits of PlantUML and the C4 model for providing a simple way of describing and communicate software architectures
0 人关注
caddy-based-magento
A docker-composed based platform for running Magento 2 with Caddy server V2.
0 人关注
calculus
0 人关注
CanvasBlocker
A Firefox extension to protect from being fingerprinted.
0 人关注
Cloudflare-CNAME-Setup
Cloudflare Partner Panel
PHP · 0 人关注
composer-merge-plugin
Merge one or more additional composer.json files at Composer runtime
0 人关注
configsync
A module to store Magento configuration with multiple environments in the version control
0 人关注
cookie-quick-manager
An addon to manage (view, search, create, edit, remove, backup, restore) cookies on Firefox.
C · 0 人关注
coturn
coturn TURN server project
Python · 0 人关注
customer-service-api
customer service api site.
JavaScript · 0 人关注
customer-service-web
customer service web site.
0 人关注
docker
Dockerfile · 0 人关注
docker-alpine
golang server定制apine
Dockerfile · 0 人关注
docker-debian-dev
docker debian for dev.
Dockerfile · 0 人关注
docker-es
elasticsearch configured for chinese.
JavaScript · 0 人关注
dva
🌱 React and redux based, lightweight and elm-style framework. (Inspired by elm and choo)
Go · 0 人关注
echo-swagger
echo middleware to automatically generate RESTful API documentation with Swagger 2.0.
 |
webeeV2EX 第 27033 号会员，加入于 2012-09-21 19:38:08 +08:001
 17  37  |
webee
| 使用 react 写了个网页版数独工具 分享创造 • webee • 2020-08-19 13:32:41 PM • 最后回复来自 adminharlem | 7 |
| 关于复杂网站的前端并行爬取方式 分享创造 • webee • 2019-07-11 17:30:48 PM • 最后回复来自 yangweijie | 9 |
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(不换选中概率)
也可以换的方式思考：
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 端和负载均衡的主动通信就可以了。
另外，服务器认为自己空闲，不代表它处理得就更快，也就不一定能降低平均延迟。
在现实情况下，主动式负载均衡除了增加系统交互复杂度，好像不比其他的负载均衡策略更好。
你要的负载均衡是以增加至少 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 端做改进，没必要添加中间层啊？
Select Language