g*****g
发帖数: 34805 | 1 有问题，银行撑不了那么快的交易速度。所以订单下到cassandra里，弄个几十个线程
的threadpool
慢慢做后台处理才是王道。 |
|
p*****2
发帖数: 21240 | 2
nosql都不支持transaction, 不过app可以handle。具体细节我也没看goodbug怎么
handle。
感觉还是event driven更自然。
@goodbug
你起threadpool去poll cassandra， 具体任务怎么分配呢？这个能zkss吗？比如同一
个车次的booking如果不同的thread拿到如何？ |
|
N*****m
发帖数: 42603 | 3 没做过，用过。当然知道怎么做，java的websocket是用threadpool+blocking queue实
现的。根本不是啥难题。 |
|
g*****g
发帖数: 34805 | 4 蜥蜴反驳了以下那个说fp从运行效率到开发效率都秒了java的，你就迫不及待出来反驳。
你根本就没写过什么java复杂多线程的程序，才会成天说java程序员乱加锁。
concurrency package
在那里，java程序员根本就是尽量避免用synchronized的，绝大多数问题结合Atomic
type, BlockingQueue, ThreadPool这些足够了。java 1.5都快10年了，你还抱着老皇
历，可笑至极。 |
|
D*******a
发帖数: 3688 | 5 你可以用boost asio来做threadpool，就不用担心thread之间分配任务不均的问题。
stackoverflow有例子。 |
|
g*****g
发帖数: 34805 | 6 client 端起个threadpool支持伪async的是有一些，比如MariaDB就有这样的client，
完整的服务器async支持就还没有见到。 |
|
g*****g
发帖数: 34805 | 7 关于数字，你完全看错了。我说的是每台机器起10个VM, 每个VM 50K，这样一个是不用
bind 多个IP, 另一个是memory footprint不会太大。我用了200个VM去支持1000万并发
用户, 但底下的机器肯定多于20个，我有多个cluster跑不同的服务。这个相当于一台
物理机器0.5M用户，而且是三年前的机器。你要说做得不如WhatsApp或者Google，很有
可能，但数量级的差距是不至于的。
如果我的系统瞬间增加20%的连接请求，在应用服务器threadpool queue达到设定上限
之后，后面的请求会被拒绝或timeout。不会导致系统崩溃。这种设计针对的是DOS, 以
及不可预计的情况。而200个VM里，一个或几个VM同时当掉，是可以预期并且必须无缝
解决的。从概率上，除非整个数据中心坏了，不会出现20%的VM当掉的情况。 |
|
g*****g
发帖数: 34805 | 8 关于数字，你完全看错了。我说的是每台机器起10个VM, 每个VM 50K，这样一个是不用
bind 多个IP, 另一个是memory footprint不会太大。我用了200个VM去支持1000万并发
用户, 但底下的机器肯定多于20个，我有多个cluster跑不同的服务。这个相当于一台
物理机器0.5M用户，而且是三年前的机器。你要说做得不如WhatsApp或者Google，很有
可能，但数量级的差距是不至于的。
如果我的系统瞬间增加20%的连接请求，在应用服务器threadpool queue达到设定上限
之后，后面的请求会被拒绝或timeout。不会导致系统崩溃。这种设计针对的是DOS, 以
及不可预计的情况。而200个VM里，一个或几个VM同时当掉，是可以预期并且必须无缝
解决的。从概率上，除非整个数据中心坏了，不会出现20%的VM当掉的情况。 |
|
g*****g
发帖数: 34805 | 9 光executor, task之间无关的都不好意思说是多线程。怎么也得是一堆的Future,
CountDownLatch, Lock, 在threadpool里还有先后关系，一不小心会死锁的才能叫多线
程。 |
|
g*****g
发帖数: 34805 | 10 Threadpool是用来支持OS上的blocking call，不是用来跑你的代码的。 |
|
p*****2
发帖数: 21240 | 11
用fixed threadpool akka会比future快吗？ 感觉都是share同样数目的threads。 |
|
g*****g
发帖数: 34805 | 12 难道大部分时候不是有个Threadpool就行了吗，ExecutorService. |
|
g*****g
发帖数: 34805 | 13 原则就是不要乱开线程，要用 config好的 threadpool, 要让 container管理这样
shutdown server的时候是可控的。spring也是个 container.
虽然不用管理 pool, 还是多线程，有没有问题在于有没有共享资源。比如一个 bean里
有个简单计数器，是一定会出问题的。
container |
|
|
g*****g
发帖数: 34805 | 15 You should use threadpool and built in JMX for monitoring. |
|
w**z
发帖数: 8232 | 16 我本人在tomcat 里用过一次ExecutorService. 有个request 进来，要update
multiple Cassandra row，
一般情况下，在servlet container 里不用自己threadpool， container 已经有了自
己的 service thread pool. 每个request 都分配一个service thread
后来tomcat 加了 nio
http://java.dzone.com/articles/understanding-tomcat-nio
|
|
n*********u
发帖数: 1030 | 17
我有些native library产生的object，init比较慢，内存消耗也有点大。
让tomcat之类的自己管理thread的话，每个thread都要init一遍（慢），thread多的话
总内存消耗也会很厉害。
所以放个threadpool在那儿共享几个这样的object会比较好吧？ |
|
g*****g
发帖数: 34805 | 18 Threads in threadpool typically don't die, instead of using Thread.join, you
should simple block on Fugure.get
thread |
|
T*****e
发帖数: 361 | 19 哈哈，当时用多线程已经是头一次了，很多方面都没考虑到/对，还是走了一些弯路的
。threadpool当时没用好像是因为没有看到线程配对（一个工作一个监测控制）的例子
，自己不知道如何着手。
JMX没有接触过，到现在也只是听说过。看来有空可以看看。
当时考虑过用Message Queue来做调度，不过没找到persistency和recovery方面的资料
（主要是这个也是似懂非懂），后来直接把调度做成数据库的更新与查询了事。
后来学scala的actor，觉得akka的actor就挺好挺简单，不过重写是不可能了。 |
|
g*********9
发帖数: 1285 | 20 我们也就用用DI, configuration,偶尔用用AOP, multithreading都是自己写，java
threadpool 用着很方便。用framework，感觉就是搭程序，死记硬背的东西太多，很多
东西都是不停的试，好用的话save下来，下次直接copy,很无聊。 |
|
|
w***g
发帖数: 5958 | 22 一个queue，所有的请求都往这个queue里送，然后所有的thread都从这个queue里获取
任务。1个queue比N个queue更优是排队论的基本结论。goodbug说的专门用一个pool来
做调度是over engineering。
queue |
|
h*******u
发帖数: 15326 | 23 单队未必比多队更优，
要看任务类型以及scheduling方式 |
|
g*****g
发帖数: 34805 | 24 你这个显得缺乏经验呀。不是说不可以只用一个线程池，如果任务都简单快速当然可以
，比如CRUD网站。
但是但凡任务时间或数目有显著区别，多线程池就是个常见设计。多线程池可以提供独
立的SLA，调节能力，监控能力。
我举个例子，你有个零售网站，浏览很快100ms，交易要走外部信用卡比较慢5秒。这天
你特卖一东西流量大增。上俩线程池的结果就是交易有一部分要失败，但是失败得很快
，浏览基本不受影响。只有一个的话，就是所有线程都堵在缓慢的交易上，浏览
timeout。整个网站没响应。 |
|
|
k**********g
发帖数: 989 | 26
If some tasks run much quicker than some other tasks (and if there is a way
to classify tasks beforehand, before they are dispatched to queues), then it
is better to have more than one queue, with at least one queue dedicated to
the known fastest tasks and one dedicated to the known slowest tasks.
Queueing theory also explains why supermarkets have "express checkout queues
".
Sometimes we have to use the correct cost function to understand theory.
Consider that user A submits only fast tasks. U... 阅读全帖 |
|
|
h*******u
发帖数: 15326 | 28 实际上不管几个thread pool最后都堵在cpu上，而且互相影响 |
|
h*******u
发帖数: 15326 | 29 和操作系统scheduling有关
比如双线程有些情况下，cpu utilization低的时候基本每个线程获得cpu和流量成比例
，cpu满载以后每个线程基本等分 |
|
h*******u
发帖数: 15326 | 30 cpu使用率不能太高，超过阈值就要任务分流。大牛你讲讲你们现在怎么实现的 |
|
p*****2
发帖数: 21240 | 31 我现在主要是async 大运算都交给spark了
我们还没有在real time做大运算的需求
如果有的话我可能会把运算分布出去 而不是挤在一台机器上互相影响 |
|
p*****2
发帖数: 21240 | 32 cpu多少算？
我们一般不超过50%？忙的时候可以到70 |
|
h*******u
发帖数: 15326 | 33 我们全都是realtime，所以对调度要求高。
我们阈值是动态调整，但70%基本上上限了，因为任务分流也有很大cost。
spark里面大牛是怎么控制性能的？还是直接丢进去就不管了？ |
|
p*****2
发帖数: 21240 | 34 offline分析 不是太care性能
大牛能谈谈你们的架构吗
我奇怪像go这样的 貌似cpu intensive的任务也不给力 goroutine不能阻塞cpu
所以我觉得web上还是io heavy的占大多数 |
|
h*******u
发帖数: 15326 | 35 我们没有什么高大上的技术，就是自己造了些土轮子拼在一起了。
io heavy正常吧，web这种简单任务一般卡在io上吧。
任务调度我个人觉得关键是避免后面的非线性部分，系统过忙进入非线性部分以后容易
震荡。单一任务越复杂这种现象越明显。所以要把cpu util压到前面线性部分。每种系
统平台都不一样，我这些可能不适用。
大牛你们如果是计算任务恐怕会有这个问题吧。你们一个任务一般多少处理时间？ |
|
g*****g
发帖数: 34805 | 36 当然不是，通常瓶颈都在 IO上。我说的这个例子是外部网络IO, 更常见是数据库 IO
是瓶颈。如果 CPU使用率太高，你可以scale up 和 scale out. |
|
|
p*****2
发帖数: 21240 | 38 我们一般几十ms这样吧
主要都是io cost |
|
h*******u
发帖数: 15326 | 39 有道理。
前面都解释了。而且不管io怎么处理的，除非限制在物理器件上或者是中断上，io实际
上也可以看做一个thread pool，最后都堵在cpu上。你scale up当然没什么好说的了，
比如i7的机器搞串口测量，肯定cpu闲得很。 |
|
h*******u
发帖数: 15326 | 40 几十ms不算快了
大牛怎么评价你们系统的性能的？用哪些指标？ |
|
w**z
发帖数: 8232 | 41 为什么不用现成的queueing system？ 你只要create threads listening on the
queues 就好了。
queue |
|
p*****2
发帖数: 21240 | 42
主要是throughput latency了。throughput大了，tp99几十ms已经不错了。 |
|
|
g*****g
发帖数: 34805 | 44 IO bottleneck CPU%通常都不高，没有你这么解释的。换句话说，我在等数据库快不了
，但你要是来两request算PI是没问题的。 |
|
w**z
发帖数: 8232 | 45 现在的queue 都是cluster 的吧，还可以persist， 比自己写一个容易多了。 而且
producer/consumer 可以是用各种语言，完全decouple 了。 |
|
|
|
a***n
发帖数: 538 | 48 kafka直接做job queue好像不是很灵活，conumser数目是固定的。
中间好像要再加一层。 |
|
|
g*****g
发帖数: 34805 | 50 只要没bug是不会造成这种情况的。io就是io，cpu就是cpu。除非是线程太多都在
context switch。比如一个web crawler，那种就应该用async io了。 |
|
