作者bluesea32541 (bluesea)
看板Grad-ProbAsk
标题[理工]108台大 计系4 8
时间Fri Jan 17 00:24:25 2020
https://i.imgur.com/8RyhyTU.jpg
https://i.imgur.com/vQC1cCO.jpg
想问这两题怎麽排
https://i.imgur.com/MhDAV0c.jpg
可以大致提一下各小题的概念吗Q
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 123.192.209.180 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/Grad-ProbAsk/M.1579191867.A.A40.html
1F：→ DLHZ: data cache我认为是最简单 不需要什麽特别的设计 应该说完全01/17 00:34
2F：→ DLHZ: 无关？然後single issue 再来是pipeline、superscalar、spec01/17 00:34
3F：→ DLHZ: ulative 最後是out of order01/17 00:34
了解～感谢！
4F：推 plsmaop: 8.（a)这种交易都很短不会拖太长，在 optimistic lock 加01/17 07:23
5F：→ plsmaop: 上 priority scheduler 先让金额高的 commit01/17 07:23
6F：推 plsmaop: 8(b)，用一个 node 给顺序，所有人第一步就是去跟那个 no01/17 07:25
7F：→ plsmaop: de 要一个严格递增的序号，结帐时出示讯号，如果上一个01/17 07:25
8F：→ plsmaop: 完成结帐是要结帐的人的序号+1才可以结帐01/17 07:25
9F：推 plsmaop: 8(c)共识演算法或 two phase commit01/17 07:28
10F：推 plsmaop: 8(d) 大量写入求 throughput 请参考 LSM 树01/17 07:29
11F：推 plsmaop: 8(e) 大量 transaction 不断 abort 导致 DDoS，用 CDN，r01/17 07:31
12F：→ plsmaop: ate limiter，或商品预先分区01/17 07:31
13F：推 DLHZ: 推大神01/17 07:36
14F：推 mistel: 请问我看书上是写说乐观并行控制不适用於大量多笔可能彼01/17 08:42
15F：→ mistel: 此冲突的交易，所以这时候适合用这个方式吗？ 我自己是写01/17 08:42
16F：→ mistel: 利用协调者决定谁可以进入临界区间(才能扣库存01/17 08:42
17F：→ mistel: 但我觉得这样效能会变差 所以不知道...01/17 08:44
18F：推 mistel: 咦等等，我看错题号了 那没事了01/17 08:47
19F：→ mistel: 所以第一题是问即使可能交易出错也没差的罗？01/17 08:47
20F：推 plsmaop: 乐观锁不会出错啦，是 commit 时决定可不可以 commit，确01/17 08:55
21F：→ plsmaop: 实你说大量冲突有可能导致效能不好，那改用悲观锁也可，01/17 08:55
22F：→ plsmaop: 我觉得重点在於 priority scheduler 选赚最多钱的 transa 01/17 08:55
23F：→ plsmaop: ction01/17 08:55
24F：→ plsmaop: postgres 就乐观锁加上 multiversion concurrency contro01/17 08:55
25F：→ plsmaop: l01/17 08:55
26F：推 mistel: 了解，那能不能再问一下c小题拿乐观锁或类似的机制来作答01/17 09:01
27F：→ mistel: 可以吗？不是很懂two-phase commit跟乐观锁或two-phase l01/17 09:01
28F：→ mistel: ocking之间的功能有什麽差异01/17 09:01
29F：推 plsmaop: two phase commit 是分散式系统之间维持一致性，two phas01/17 09:15
30F：→ plsmaop: e lock 是同一台电脑上不同 transaction 在存取相同的东01/17 09:15
31F：→ plsmaop: 西时确保交易正确且不会出现死锁01/17 09:15
32F：推 plsmaop: 乐观锁跟多版本并行是一起的，transaction 开始时该 tran01/17 09:18
33F：→ plsmaop: saction 会记住开始时资料的模样，给一个版号然後直接修01/17 09:18
34F：→ plsmaop: 改，commit 时检查自己的版号是不是最新的，不是就得 abo01/17 09:18
35F：→ plsmaop: rt01/17 09:18
36F：推 plsmaop: 悲观锁则是要存取资料前一定要取得锁才行，然後加上 2PL01/17 09:21
37F：→ plsmaop: 来确保同时处理的 transaction 们的执行结果跟一个一个01/17 09:21
38F：→ plsmaop: 处理时是一样的（serializable）01/17 09:21
39F：→ plsmaop: 如果还要考虑 transaction abort 所造成 phantom read，01/17 09:22
40F：→ plsmaop: 就要采用 strict 2PL01/17 09:22
41F：推 mistel: 我懂了！！谢谢p大 讲的好清楚01/17 09:24
42F：推 plsmaop: 上面有错喔，2PL 还是有死锁，2PL 的重点在於确保 serial01/17 09:24
43F：→ plsmaop: izability，就是多个 transaction 同时进行，但结果必须01/17 09:24
44F：→ plsmaop: 跟一个一个处理多个 transaction 一样 01/17 09:24
感谢p大！！真的很详细
※ 编辑: bluesea32541 (123.192.209.180 台湾), 01/17/2020 10:29:37
45F：推 ccapricorntw: 4c 我是排container>VM>GPGPU>Hyper-thread>supersc 01/17 16:20
46F：→ ccapricorntw: aler>pipeline 不过不是很确定 01/17 16:20
47F：推 ccapricorntw: 另外想问一下一楼D大为何speculative会比superscale 01/17 16:23
48F：→ ccapricorntw: r难处理exception？ 01/17 16:23
49F：→ DLHZ: 我好像想错了 speculative的部分应该跟exception的处理没什 01/17 16:56
50F：→ DLHZ: 麽关系 而且看起来不代表他有pipeline? 01/17 16:56
51F：→ DLHZ: 我重新排一次好了 cache无关最简单 然後我再想了一次认为sin 01/17 16:57
52F：→ DLHZ: gle issue, speculative, superscalar一样 让control signal 01/17 16:57
53F：→ DLHZ: 去改pc就好 再来pipeline 最後out of order+superscalar 01/17 16:57
54F：→ DLHZ: 抱歉跟前面差有点多 想的太随便== 01/17 17:00
55F：→ DLHZ: superscalar还是复杂一点(unit较多)然後speculative中像BTB 01/17 17:06
56F：→ DLHZ: 之类的可能还是要处理 但是相对较少 所以那三个再分下来应该 01/17 17:06
57F：→ DLHZ: 是 single issue, speculative, superscalar 01/17 17:06
58F：→ DLHZ: 崩溃 大家看看就好 我越想越不对劲 01/17 17:17
59F：推 ccapricorntw: XD 但我认为pipeline比较简单耶 pipeline如果在EXE 01/17 17:47
60F：→ ccapricorntw: 发生exception 顶多flush IF跟ID的指令 01/17 17:48
61F：→ ccapricorntw: 但是superscalar可能要flush所有unit的指令 01/17 17:48
62F：→ DLHZ: 我想说以pipeline的设计还要决定flush哪里 如果比较简易的只 01/17 21:07
63F：→ DLHZ: 要让他全部flush就好 01/17 21:07
64F：→ ccapricorntw: superscalar也不一定全flush吧？应该只会flush在 01/17 22:15
65F：→ ccapricorntw: 原本order发生exception的指令後的指令吧？ 01/17 22:15
66F：→ DLHZ: 因为他只有说superscalar 我想说不一定是pipeline吧？ 01/17 22:23
67F：→ ccapricorntw: 也是 不过有没有pipeline的运作上有甚麽差R？ 01/17 22:34
68F：→ ccapricorntw: 这块不太熟QQ 01/17 22:35
69F：→ DLHZ: 有pipeline应该就是单纯分阶段?不过所有superscalar的例子 01/17 22:38
70F：→ DLHZ: 都是implement在pipeline上 这也是我的猜测而已 01/17 22:38
71F：推 dsa66253: 请问p大 这些内容是在分散式系统里吗？应该是要修什麽 01/18 23:52
72F：→ dsa66253: 课程比较能够有通盘理解？ 01/18 23:52