-
课程简介 5
-
Lecture1.1
-
Lecture1.2
-
Lecture1.3
-
Lecture1.4
-
Lecture1.5
-
-
Amazon Web Services基础 7
-
Lecture2.1
-
Lecture2.2
-
Lecture2.3
-
Lecture2.4
-
Lecture2.5
-
Lecture2.609 min
-
Lecture2.7
-
-
Identity Access Management (IAM) – 身份认证服务 3
-
Elastic Compute Cloud (EC2) – 计算服务 24
-
Lecture4.1
-
Lecture4.2
-
Lecture4.3
-
Lecture4.4
-
Lecture4.5
-
Lecture4.619 min
-
Lecture4.719 min
-
Lecture4.815 min
-
Lecture4.915 min
-
Lecture4.1010 min
-
Lecture4.1125 min
-
Lecture4.1211 min
-
Lecture4.1314 min
-
Lecture4.1408 min
-
Lecture4.1532 min
-
Lecture4.1617 min
-
Lecture4.1720 min
-
Lecture4.1825 min
-
Lecture4.1929 min
-
Lecture4.2018 min
-
Lecture4.2123 min
-
Lecture4.2212 min
-
Lecture4.2322 min
-
小测4.110个问题
-
-
Simple Storage Service (S3), Glacier, CloudFront – 存储服务 16
-
Lecture5.1
-
Lecture5.2
-
Lecture5.308 min
-
Lecture5.410 min
-
Lecture5.506 min
-
Lecture5.621 min
-
Lecture5.706 min
-
Lecture5.805 min
-
Lecture5.910 min
-
Lecture5.1027 min
-
Lecture5.1115 min
-
Lecture5.1220 min
-
Lecture5.1315 min
-
Lecture5.1418 min
-
Lecture5.1520 min
-
小测5.115个问题
-
-
Virtual Private Cloud (VPC) – 网络服务 12
-
Lecture6.120 min
-
Lecture6.235 min
-
Lecture6.320 min
-
Lecture6.425 min
-
Lecture6.510 min
-
Lecture6.620 min
-
Lecture6.710 min
-
Lecture6.810 min
-
Lecture6.915 min
-
Lecture6.1014 min
-
Lecture6.1115 min
-
小测6.19个问题
-
-
Route53 – DNS服务 9
-
Lecture7.115 min
-
Lecture7.215 min
-
Lecture7.310 min
-
Lecture7.415 min
-
Lecture7.510 min
-
Lecture7.620 min
-
Lecture7.710 min
-
Lecture7.810 min
-
小测7.110个问题
-
-
RDS, DynamoDB Database – 数据库服务 9
-
Lecture8.120 min
-
Lecture8.225 min
-
Lecture8.320 min
-
Lecture8.420 min
-
Lecture8.505 min
-
Lecture8.610 min
-
Lecture8.705 min
-
Lecture8.810 min
-
小测8.110个问题
-
-
应用服务(SQS, SWF, SNS等) 8
-
Lecture9.120 min
-
Lecture9.210 min
-
Lecture9.310 min
-
Lecture9.410 min
-
Lecture9.505 min
-
Lecture9.615 min
-
Lecture9.715 min
-
小测9.19个问题
-
-
其他服务 10
-
Lecture10.115 min
-
Lecture10.215 min
-
Lecture10.315 min
-
Lecture10.410 min
-
Lecture10.515 min
-
Lecture10.605 min
-
Lecture10.718 min
-
Lecture10.818 min
-
Lecture10.911 min
-
Lecture10.1013 min
-
-
真实的高可用AWS架构方案 7
-
Lecture11.120 min
-
Lecture11.230 min
-
Lecture11.320 min
-
Lecture11.425 min
-
Lecture11.510 min
-
Lecture11.610 min
-
Lecture11.720 min
-
-
AWS认证考试白皮书 8
-
Lecture12.115 min
-
Lecture12.215 min
-
Lecture12.320 min
-
Lecture12.420 min
-
Lecture12.520 min
-
Lecture12.6
-
Lecture12.715 min
-
Lecture12.820 min
-
-
综合测试题 1
-
小测13.165个问题
-
-
考试指南 3
-
Lecture14.105 min
-
Lecture14.210 min
-
Lecture14.305 min
-
15个评论
请问这一题:ELC有一条特性是Automatic detection and recovery from cache node failures.为什么答案选项还需要部署到两个AZ 去,
Your application is using an ELB in front of an Auto Scaling group of web/application servers deployed across two AZs and a Multi-AZ RDS Instance for data persistence. The database CPU is often above 80% usage and 90% of I/O operations on the database are reads. To improve performance you recently added a single-node Memcached ElastiCache Cluster to cache frequent DB query results. In the next weeks the overall workload is expected to grow by 30%. Do you need to change anything in the architecture to maintain the high availability or the application with the anticipated additional load? Why?
• Yes, you should deploy two Memcached ElastiCache Clusters in different AZs because the RDS instance will not be able to handle the load if the cache node fails.
• No, if the cache node fails you can always get the same data from the DB without having any availability impact.
• No, if the cache node fails the automated ElastiCache node recovery feature will prevent any availability impact.
• Yes, you should deploy the Memcached ElastiCache Cluster with two nodes in the same AZ as the RDS DB master instance to handle the load if one cache node fails.
肯定还是需要的,如果cache节点放在一个可用区,当这个可用区出现了故障的话,这个cache节点就挂了。这样会导致程序读不到cache,会去读数据库,当然数据库也有数据,只是应用程序连接cache的时候会超时,整个用户体验下来会很差。
在实际场景中,如果我们有对数据库的读写有很高的要求,并且数据的更新没有那么频繁,我们就可以考虑使用Elasticache来减少我们的数据库负担,增加数据库读取的性能。
读写要求高并且更新不频繁,这句怎么理解?写入不就是更新吗?
一般缓存适用于,读取频率很高,或者写入(新数据)频率很高,这种场景的缓存命中率会高,效率好一些。如果频繁更新数据,就需要刷新缓存,保证缓存的数据是最新的。
前面说更新频繁的热数据存储在elasticcache,后边的redis说如果数据更新不频繁,可以考虑使用elasticcache,前后矛盾吧?
您好,请问在CDN层面,有没有可能实现类似的数据库缓存呀。谢谢
不太一样喔,一个是文件类型的缓存,一个是数据的缓存。
如果都是异步方式更新数据库,什么情况下会两边同时写?
那更新Elasticache的数据后,它是以异步的方式更新到数据库吗
对的,一般是异步方式来更新。
挺好的
为什么把更新不频繁的数据放到elasticache中?我们对elasticache中数据进行写的操作,会同步到数据库中吗,elasticcache 会与只读有交付吗?一条请求过来是先访问elasticache,如果elasticache中没有再访问数据库,在相应的同时会对elasticache进行更新,是这一个流程吗?
这个之前教程写反了,应该是把频繁访问的数据放到Elasticache中,因为这样可以更好地利用高速缓存。
另外,先访问哪一种数据库是又应用程序来决定的。读取的话,一般来说最佳实践是先访问Elasticache,然后没有命中的话再去访问数据库;写入的话两边同时都会写入。但还需要根据具体数据的“冷”“热”程度来做特殊辨别。
在实际场景中,如果我们有对数据库的读写有很高的要求,—–> 这句话里面的读写有很高要求,应该是读取吧?
Elasticache也可以写入哟~