tumblr服务器地址是多少？

域名：tumblr.cc

获取IP地址：162.251.5.190

数字地址：2734359998

IP物理地址：北美地区

扩展资料：

负面消息

大陆封锁

Tumblr的绑定域名IP在2007年10月16日左右被封锁。

Tumblr主站则在11月22日左右被彻底封锁。此后Tumblr被完全封锁，虽几次更改IP但都没有能稳定访问过，2010年4月3日至月底。2010年3月开始大陆已有部分用户可以直接上Tumblr，到四月底已经完全解封，大陆可以直接上Tumblr。

但从2012年四月起，因不明原因，Tumblr主站突然变得不稳定，需加https才可访问，速度极慢。2013年1月访问速度又恢复正常。2013年4月后已被中国大陆屏蔽。2013年5月15日，网友发现可以正常访问了！

业绩不实

Tumblr并未透露每月活跃用户的数量。据卡夫卡援引一位知情人士的话称，Tumblr的活跃用户数量可能只有3000万到5000万，这一数额与每月3亿独立用户数量相比，落差很大。

雅虎称，该公司将开始在Tumblr的活跃页面上发布广告，但需要得到用户的同意，这也就意味着，在这3亿用户中，只有一小部分的用户能够看到广告内容。

当然，Tumblr的业务泼凉水的并非只有卡夫卡一人的报告。

事实上，据硅谷的分析师也发布报告称，Tumblr2012年的营收不到500万美元，这一数据的确令人吃惊，因为大家此前一直都从《福布斯》的报道中获悉，Tumblr2012年的营收为1300万美元。

另外，在一些有关雅虎与Tumblr交易的报告还提到，Tumblr2013年的营收可能将达到1亿美元，而业界一些人士认为，Tumblr2013的营收可能只有1500万美元，这一差距也令人震惊。

无论如何，目前来看，Tumblr在2013年的营收要想达到1亿美元，那将会非常困难。

参考资料来源：百度百科-tumblr

Kafka是一个分布式发布-订阅publish-subscribe消息传递系统，设计目标是快速、可伸缩和耐用冗余。

它是一个在一个较高的抽象水平上描述的但是又非常简单的系统，虽然当你更深地挖掘时会令人难以置信的技术细节。卡夫卡文档出色的解释了系统中许多设计和实现的微妙之处，所以我们不会在这里试图解释他们了。

像许多发布-订阅消息传递系统，卡夫卡能保存源消息的数据。生产者将输入写入到主题topic，而消费者则从主题topic中读取写入数据。因为卡夫卡是一个分布式系统，所以topic主题会实现跨多个节点分区和复制。

消息是简单byte数组，开发者能够使用它们存在对象的任何格式，如String或JSON和Avro，每个消息能够有一个Key，因此，生产者保证拥有相同key的消息到达同一个分区，而对主题topic的消费，可以使用多个消费者来配置消费组，每个消费组中消费者能够从他订阅的那个主题Topic所在分区子集中读取消息，这样每个消息发送给消费组中一个消费者，使用相同key的所有消息能够到达相同的消费者。

Kafka的特点是它将每个主题topic分区都看成一个日志log(一个有顺序的消息集合)，一个分区中的每个消息被分配一个唯一的偏移量offset.

Kafka并不试图跟踪哪个消息被哪个消费者读取，而是只是保留未被读取的消息。

Kafka保留所有消息的时间，而消费者负责跟踪它们在每个日志(日志是一个消息序列集合代表一个topic分区)中的位置，

因此Kafka能够支持大量的消费者，使用最小的代价保留大量的数据。

Kafka如何工作?

假设我们正在开发一个大型多人在线游戏。在这些游戏中,玩家在一个虚拟的世界中互相合作和竞争。通常玩家互相发生贸易，比如交换物品和金钱，所以游戏开发者重要的是要确保球员不会欺骗，在下面两种情况下的交易将标记为特殊：如果贸易数量明显大于正常的球员如果IP玩家登录是不同于过去的20场比赛使用的IP。除了对实时交易进行标记以外，我们也想加载数据到Apache

Hadoop，我们的数据,科学家们可以用它来训练和测试新算法。

基于游戏服务器内存数据缓存进行实时事件标记是最好的，能够让我们达到迅速决定，特别是对那些最活跃玩家。如果我们分区游戏服务器，我们的系统有多个游戏服务器和数据集，，包括过去登录的20个玩家和近20在内存的交易,。

我们的游戏服务器必须执行两个截然不同的角色：第一个是接受和执行用户操作，第二是实时处理贸易信息并标记可疑事件。为了有效执行第二个角色功能，每个用户整个贸易的历史事件都驻留在一个单独的服务器内存中。因为接收用户操作(第一个角色功能)的服务器可能没有他的贸易历史，这意味着我们必须通过服务器之间的消息实现第二个角色功能。为了让两个角色功能保持松散耦合,我们使用卡夫卡在服务器之间传递消息,您将看到如下：

卡夫卡有几个特性：

可伸缩性、数据分区,低延迟,并且能够处理大量不同的消费者。我们为登录和交易配置了一个Topic主题。我们把它们配置成一个topic主题的原因是：只有我们获得已经登录信息(我们可以确保玩家从他平时IP登录)后，才能确保他的交易是有效的。卡夫卡可以在在一个主题topic中维护这个前后顺序，而不是在两个topic之间。

当用户登录后进行交易，接受服务器立即发送事件到Kafka. 消息是将user id作为key, 事件作为值.

这能确保同一个用户的所有交易和登录发送到Kafka同样的分区. 每个事件处理服务器都运行一个Kafka消费者,

其每个消费者都被配置为同样组的一部分，这样，每个服务器从少量Kafka分区读取消息，所有关于某个特定用户的数据都能发往相同事件处理服务器，当事件处理服务器从Kafka读取一个用户交易时，将这个事件加入到用户事件历史缓存本地内存缓存，这样就无需额外网络磁盘开销直接标记那些可以事件。

重要的是我们为每个事件处理服务器创建一个分区，或者每个事件处理服务器上每核对应一个多线程应用，(记住 Kafka大部分是用少于 10,000

个分区实现所有主题topic，这样我们不能为每个用户创建一个分区，因为用户数是不断增加的。)

这好像是一种迂回方式处理事件：从游戏服务器发送事件到Kafka,

另外一台服务器读取这个事件再处理它，这种设计解耦了两种角色功能，允许我们为每个角色功能安排其需要的容量与能力。.另外，这样做不会增加处理时间，因为Kafka是设计为高吞吐量和低延迟的，即使只有一个小的三台节点服务器的集群环境，也能每秒处理接近一百万个事件，平均延迟只有3ms.

当服务器标识出一个事件作为可疑，它会发送这个标记了的事件到新的Kafka

topic，比如其主题名称为Alerts，这时报警服务器或仪表监控服务器会接受到这个事件，同时另外一个单独过程会从Alerts主题中读取这个事件，将它写入到Hadoop进行更进一步分析。

因为Kafka并不跟踪确认每个消费者的消息，它就能用很少的性能影响处理成千上万的消费者。Kafka甚至可以处理批量消费者：每一个小时处理过程唤醒激活处理一个队列中所有消息，根本就不会影响系统的吞吐量或延迟。

---