用户数据的存储
Storage of user data
在查看 Facebook 等网站如何存储个人资料图片时，URL 似乎使用随机生成的值。比如Google的Facebook page的头像页有如下URL:
https://scontent-lhr3-1.xx.fbcdn.net/hprofile-xft1/v/t1.0-1/p160x160/11990418_442606765926870_215300303224956260_n.png?oh=28cb5dd4717b7174eed44ca5279a2e37&oe=579938A8
但是为什么不这样组织呢:
https://scontent-lhr3-1.xx.fbcdn.net/{{ profile_id }}/50x50.png
显然，就存储和简单性而言，这会容易得多。我错过了什么吗？谢谢
通过你的路由方案，你会如何避免陌生人访问私人账户的图片？哈希值还可以防止机器人下载所有图片。
像 Facebook 这样的公司拥有相当密集的 CDN。它们可能看起来像是随机生成的 url，但实际上并非如此，每条单独的路线都是有目的的，并经过编程以这种方式处理。
它们并不像您只是使用 FTP 连接到基本的营销网站服务器那样追求存储的简单性。虽然您可以将所有图像放在 /images 文件夹中，但 Facebook 对此来说太复杂了。数十种不同类型的应用程序访问全球数百甚至数千个 CDN 和服务器。
如果您曾经在 Rails 应用程序上构建过一个网络应用程序，例如 Ruby，并且您使用 AWS（亚马逊网络服务）等服务，您也会遇到似乎像荒谬的 urls。但它都是架构内提供的快速交付网络的一部分。每次你 "push" 你的应用程序到服务器时，都会为每个唯一资源自动生成新的 urls，css 文件，JavaScript 文件，图像文件等都是动态创建的.您不必在每次发布应用程序时分别输入这些唯一的 url，代码只知道在发布过程中在哪里查找它们。
示例：您告诉网络应用程序查找
//= require jquery
它 returns 你 http://example.com/assets/jquery-eb3e278249152b5b5d5170b73d9dbf52.js?body=1 在你的 header.
url 比它应该的更复杂并不重要，应用程序可以识别它，这才是最重要的。
我明白你的痛苦 :-) 我可能不会继续描述这个问题如何出现更多，而是让我谈谈解决方案。好吧，在一般代码中处理散列值甚至 base64ed 值时看起来很乱是很正常的，但是随着标识符的解释，它不会留下太多！
我曾经在一家我们用来整理 Facebook post 的公司工作，使用 Graph API 获取其 Insights 对象并从中提取信息以便于在 UI 中传递并发送回我们的 Redis 缓存存储；一旦我们在 TaffyDB 中定义了一个数据结构，对象组织将是什么样子，一切就变得有意义了，因为它能够从看起来很长的垃圾流中查询有用的有限流 Javascript 流
参考：http://www.taffydb.com/
简单来说，我认为可以归结为两个主要原因：安全和缓存：
安全性 - 添加这些不可预知的长哈希值可以防止其他人猜测照片 URLs 并使您很难下载不应该下载的照片。
考虑一下，如果我可以轻松猜出您的个人资料照片 URL 并下载它，即使您明确选择只与朋友分享，会发生什么。
缓存 - 通过向每张照片添加 "random" 查询参数，确保每个照片实例都有自己的 URL。因此，您可以将照片长期存储在浏览器的缓存中，知道无论何时用新照片替换它，新照片都会有一个新的 URL 并且浏览器不会继续向您显示旧照片。
如果您要为每个用户的个人资料照片保持相同 URL（例如 https://scontent-lhr3-1.xx.fbcdn.net/{{ profile_id }}/50x50.png），然后上传新照片，则可能会发生以下任一情况：
- 如果你在浏览器的缓存中保存了很长时间的照片，浏览器会一直显示缓存的版本（只要URL是一样的，缓存没过期就没必要重新下载图像）。
- 相反，如果您只是将图像在缓存中保留一小段时间，您最终会比实际需要更多地访问服务器，从而增加负载并损害性能。
我希望这能澄清它。
URL 中的额外值可用于：
跟踪访问。这就像报纸在文章 URL 后附加“&homepage”与“&email”，因此他们的系统知道 reader 如何找到该页面。
避免滥用并控制访问。想象一下，用户将一个小的、流行的色情图片加载到个人资料图片中。然后他们可以劫持 CDN 成为他们色情网站的免费网络主机。但是 CDN 在内部使用该代码来限制视图的数量。
在查看 Facebook 等网站如何存储个人资料图片时，URL 似乎使用随机生成的值。比如Google的Facebook page的头像页有如下URL:
https://scontent-lhr3-1.xx.fbcdn.net/hprofile-xft1/v/t1.0-1/p160x160/11990418_442606765926870_215300303224956260_n.png?oh=28cb5dd4717b7174eed44ca5279a2e37&oe=579938A8
但是为什么不这样组织呢:
https://scontent-lhr3-1.xx.fbcdn.net/{{ profile_id }}/50x50.png
显然，就存储和简单性而言，这会容易得多。我错过了什么吗？谢谢
通过你的路由方案，你会如何避免陌生人访问私人账户的图片？哈希值还可以防止机器人下载所有图片。
像 Facebook 这样的公司拥有相当密集的 CDN。它们可能看起来像是随机生成的 url，但实际上并非如此，每条单独的路线都是有目的的，并经过编程以这种方式处理。
它们并不像您只是使用 FTP 连接到基本的营销网站服务器那样追求存储的简单性。虽然您可以将所有图像放在 /images 文件夹中，但 Facebook 对此来说太复杂了。数十种不同类型的应用程序访问全球数百甚至数千个 CDN 和服务器。
如果您曾经在 Rails 应用程序上构建过一个网络应用程序，例如 Ruby，并且您使用 AWS（亚马逊网络服务）等服务，您也会遇到似乎像荒谬的 urls。但它都是架构内提供的快速交付网络的一部分。每次你 "push" 你的应用程序到服务器时，都会为每个唯一资源自动生成新的 urls，css 文件，JavaScript 文件，图像文件等都是动态创建的.您不必在每次发布应用程序时分别输入这些唯一的 url，代码只知道在发布过程中在哪里查找它们。
示例：您告诉网络应用程序查找
//= require jquery
它 returns 你 http://example.com/assets/jquery-eb3e278249152b5b5d5170b73d9dbf52.js?body=1 在你的 header.
url 比它应该的更复杂并不重要，应用程序可以识别它，这才是最重要的。
我明白你的痛苦 :-) 我可能不会继续描述这个问题如何出现更多，而是让我谈谈解决方案。好吧，在一般代码中处理散列值甚至 base64ed 值时看起来很乱是很正常的，但是随着标识符的解释，它不会留下太多！
我曾经在一家我们用来整理 Facebook post 的公司工作，使用 Graph API 获取其 Insights 对象并从中提取信息以便于在 UI 中传递并发送回我们的 Redis 缓存存储；一旦我们在 TaffyDB 中定义了一个数据结构，对象组织将是什么样子，一切就变得有意义了，因为它能够从看起来很长的垃圾流中查询有用的有限流 Javascript 流 参考：http://www.taffydb.com/
简单来说，我认为可以归结为两个主要原因：安全和缓存：
安全性 - 添加这些不可预知的长哈希值可以防止其他人猜测照片 URLs 并使您很难下载不应该下载的照片。
考虑一下，如果我可以轻松猜出您的个人资料照片 URL 并下载它，即使您明确选择只与朋友分享，会发生什么。
缓存 - 通过向每张照片添加 "random" 查询参数，确保每个照片实例都有自己的 URL。因此，您可以将照片长期存储在浏览器的缓存中，知道无论何时用新照片替换它，新照片都会有一个新的 URL 并且浏览器不会继续向您显示旧照片。
如果您要为每个用户的个人资料照片保持相同 URL（例如 https://scontent-lhr3-1.xx.fbcdn.net/{{ profile_id }}/50x50.png），然后上传新照片，则可能会发生以下任一情况：
- 如果你在浏览器的缓存中保存了很长时间的照片，浏览器会一直显示缓存的版本（只要URL是一样的，缓存没过期就没必要重新下载图像）。
- 相反，如果您只是将图像在缓存中保留一小段时间，您最终会比实际需要更多地访问服务器，从而增加负载并损害性能。
我希望这能澄清它。
URL 中的额外值可用于：
跟踪访问。这就像报纸在文章 URL 后附加“&homepage”与“&email”，因此他们的系统知道 reader 如何找到该页面。
避免滥用并控制访问。想象一下，用户将一个小的、流行的色情图片加载到个人资料图片中。然后他们可以劫持 CDN 成为他们色情网站的免费网络主机。但是 CDN 在内部使用该代码来限制视图的数量。