分类目录归档：开发dev

负载均衡方案

发表评论

1.HTTP重定向负载均衡

根据用户的HTTP请求计算一台真实的Web服务器地址，并将改Web服务器地址写入HTTP重定向响应中（响应状态码302）返回给用户浏览，浏览器得到ip真实地址再重新请求实际物理服务器ip地址，完成访问。

优点：设计简单

缺点：浏览器需要两次请求服务器才能完成一次访问，性能较差；

阅读全文

nginx配置https

发表评论

最近做点小程序，服务端api必须是https域名，配置方法如下：

创建ssh证书

生成CA证书： cd /home/openssl openssl genrsa -des3 -passout pass:123456 -out test.pem 2048 #生成RSA私钥 openssl rsa -passin pass:123456 -in test.pem -out test.key #提取密钥中的公钥 openssl req -new -key test.key -out test.csr -subj /C=CN/ST=beijing/L=beijing/O=YAN/CN=www.yanjingang.com #生成证书请求文件 openssl

阅读全文

深入理解PHP7内核之zval

发表评论

PHP7已经发布, 如承诺, 我也要开始这个系列的文章的编写, 主要想通过文章让大家理解到PHP7的巨大性能提升背后到底我们做了什么, 今天我想先和大家聊聊zval的变化. 在讲zval变化的之前我们先来看看zval在PHP5下面是什么样子

zval回顾

在PHP5的时候, zval的定义如下:

  1. struct _zval_struct {
  2.      union {
  3.           long lval;
  4.           double dval;
  5.           struct {
  6.                char *val;
  7.                int len;
  8.           } str;
  9.           HashTable *ht;
  10.           zend_object_value obj;
  11.           zend_ast *ast;
  12.      } value;
  13.      zend_uint refcount__gc;
  14.      zend_uchar type;
  15.      zend_uchar is_ref__gc;
  16. };

对PHP5内核有了解的同学应该对这个结构比较熟悉, 因为zval可以表示一切PHP中的数据类型

阅读全文

大数据分析新秀Pulsar vs Kafka

发表评论
一年一度由世界知名科技媒体 InfoWorld 评选的 Bossie Awards 于 9 月 26 日公布，本次 Bossie Awards 评选出了最佳数据库与数据分析平台奖、最佳软件开发工具奖、最佳机器学习项目奖等多个奖项。在 最佳开源数据库与数据分析平台奖 中，之前曾连续两年入选的 Kafka 意外滑铁卢落选，取而代之的是新兴项目 Pulsar。Bossie Awards 中对 Pulsar 点评如下：“Pulsar 旨在取代 Apache Kafka 多年的主宰地位。Pulsar 在很多情况下提供了比 Kafka 更快的吞吐量和更低的延迟，并为开发人员提供了一组兼容的 API，让他们可以很轻松地从 Kafka 切换到 Pulsar。Pulsar 的最大优点在于它提供了比 Apache Kafka 更简单明了、更健壮的一系列操作功能，特别在解决可观察性、地域复制和多租户方面的问题。在运行大型 Kafka 集群方面感觉有困难的企业可以考虑转向使用 Pulsar。”

AI 前线近一年发布了不少 Pulsar 的技术文章，我们经常被问到一个问题：Apache Pulsar 和 Apache Kafka 到底有什么不同？今天，万众期待的对比文终于来了！ 本文将详述 Pulsar 和 Kafka 消息模型之间的区别，以及 Pulsar 与 Kafka 在系统架构设计方面的差异。

在用户选择一个消息系统时，消息模型是用户首先考虑的事情。消息模型应涵盖以下

阅读全文

安全加密算法选择指南

发表评论
用途 推荐使用的安全的密码算法 常见的不安全的密码算法
对称加密 AES（密钥长度>=128bits） DES、3DES、RC2、RC4
哈希算法 SHA256或以上 MD5、SHA1
非对称加密 RSA（密钥长度>=2048   bits） RSA（密钥长度<=1024bits）
数字签名 RSA（密钥长度>=2048   bits） RSA（密钥长度<=1024bits）
密钥交换 DH（密钥长度>=2048   bits） DH(密钥长度<=1024bits)

备注：

1. AES不建议使用ECB（同样的明文总是会产生相同的密文），推荐使用CBC模式。

2. 应注意编码及加密的区别，例如base64属于编码而不属于加密。

3. 加解密中建议使用安全随机数，如java.security.SecureRandom，类Unix系统 (包括OS X):  /dev/random；不安全随机数如C标准函数random（），java.util.Random()。

阅读全文

小猪学Paddle—线性回归之房价预测

发表评论

上次我们进行了简单的环境安装和模型应用尝试，今天开始通过paddlepaddle的房价预测看一下简单的线性回归有监督模型是怎么训练出来的。

简单点说就是根据一份有标注的数据集，包含了某地区房屋的相关信息（feature）及该类房屋的标注平均价格（label），用来训练一个可以根据feature预测label的模型。具体数据字段一共14个，包含13个feature和1个label，含义如下：

属性名 解释 类型
CRIM 该镇的人均犯罪率 连续值
ZN 占地面积超过25,000平方呎的住宅用地比例 连续值
INDUS 非零售商业用地比例 连续值
CHAS 是否邻近 Charles River 离散值，1=邻近；0=不邻近
NOX 一氧化氮浓度 连续值
RM 每栋房屋的平均客房数 连续值
AGE 1940年之前建成的自用单位比例 连续值
DIS 到波士顿5个就业中心的加权距离 连续值
RAD 到径向公路的可达性指数 连续值
TAX 全值财产税率 连续值
PTRATIO 学生与教师的比例 连续值
1000(BK – 0.63)^2，其中BK为黑人占比 连续值
LSTAT 低收入人群占比 连续值
MEDV 同类房屋价格的中位数 连续值

数据示例：

整个训练过程大概分为读取数据集、定义网络结构/cost损失函数/训练参数/训练优化器、进行多轮模型迭代训练、选择训练误差最小的模型、应用模型。具体就不再赘述了，可以先阅读一下paddlepaddle的文档：http://www.paddlepaddle.org/docs/develop/book/01.fit_a_line/index.cn.html

下边是训练过程的代码和自己的理解注释，有错误欢迎指正：

vim housing_train.py #!/usr/bin/env python # -*- coding: utf-8 -*- import os import paddle.v2 as paddle import paddle.v2.dataset.uci_housing as uci_housing with_gpu = os.getenv('WITH_GPU', '0') != '0' def main(): # 0.init paddle初始化定义跑模型的设备 paddle.init(use_gpu=with_gpu, trainer_count=1) # 1.读取data数据

阅读全文

Jupyter Notebook 快速入门

发表评论

Jupyter Notebook（此前被称为 IPython notebook）是一个交互式笔记本，支持运行 40 多种编程语言。在本文中，我们将介绍 Jupyter notebook 的主要特性，以及为什么对于希望编写漂亮的交互式文档的人来说是一个强大工具。

在开始使用 notebook 之前，我们先需要安装该库。你可以在 Jupyter 官网上找到完整的步骤。

aliyun安装步骤

#0.install sudo pip install jupyter nbconvert matplotlib sudo yum install pandoc texlive tkinter tcl-devel tk-devel -y #1.get passwd sign ipython from notebook.auth import passwd; passwd() input password && get sha1 password Out[1]: 'sha1:f29ffxxxxxx:c5a57c13ee9a56618f83b3c53621xxxxxxxxxxxx' #2.conf jupyter notebook --generate-config mkdir

阅读全文

Kafka深度解析

发表评论

背景介绍

Kafka简介

Kafka是一种分布式的，基于发布/订阅的消息系统。主要设计目标如下：

  • 以时间复杂度为O(1)的方式提供消息持久化能力，并保证即使对TB级以上数据也能保证常数时间的访问性能
  • 高吞吐率。即使在非常廉价的商用机器上也能做到单机支持每秒100K条消息的传输
  • 支持Kafka Server间的消息分区，及分布式消息消费，同时保证每个partition内的消息顺序传输
  • 同时支持离线数据处理和实时数据处理

为什么要用Message Queue

  • 解耦
    在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束
  • 冗余
    有时在处理数据的时候处理过程会失败。除非数据被持久化，否则将永远丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。在被许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理过程明确的指出该消息已经被处理完毕，确保你的数据被安全的保存直到你使用完毕。
  • 扩展性
    因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的；只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
  • 灵活性 & 峰值处理能力
    在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量并不常见；如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住增长的访问压力，而不是因为超出负荷的请求而完全崩溃。
  • 可恢复性
    当体系的一部分组件失效，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。
  • 送达保证
    消息队列提供的冗余机制保证了消息能被实际的处理，只要一个进程读取了该队列即可。在此基础上，IronMQ提供了一个”只送达一次”保证。无论有多少进程在从队列中领取数据，每一个消息只能被处理一次。这之所以成为可能，是因为获取一个消息只是”预定”了这个消息，暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息，否则这个消息会被放回队列中去，在一段可配置的时间之后可再次被处理。
  • 顺序保证
    在许多情况下，数据处理的顺序都很重要。消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。IronMO保证消息浆糊通过FIFO（先进先出）的顺序来处理，因此消息在队列中的位置就是从队列中检索他们的位置。
  • 缓冲
    在任何重要的系统中，都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行—写入队列的处理会尽可能的快速，而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。
  • 理解数据流
    在一个分布式系统里，要得到一个关于用户操作会用多长时间及其原因的总体印象，是个巨大的挑战。消息系列通过消息被处理的频率，来方便的辅助确定那些表现不佳的处理过程或领域，这些地方的数据流都不够优化。
  • 异步通信
    很多时候，你不想也不需要立即处理消息。消息队列提供了异步处理机制，允许你把一个消息放入队列，但并不立即处理它。你想向队列中放入多少消息就放多少，然后在你乐意的时候再去处理它们。

常用Message Queue对比

  • RabbitMQ
    RabbitMQ是使用Erlang编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正因如此，它非常重量级，更适合于企业级的开发。同时实现了Broker构架，这意味着消息在发送给客户端时先在中心队列排队。对路由，负载均衡或者数据持久化都有很好的支持。
  • Redis
    Redis是一个基于Key-Value对的NoSQL数据库，开发维护很活跃。虽然它是一个Key-Value数据库存储系统，但它本身支持MQ功能，所以完全可以当做一个轻量级的队列服务来使用。对于RabbitMQ和Redis的入队和出队操作，各执行100万次，每10万次记录一次执行时间。测试数据分为128Bytes、512Bytes、1K和10K四个不同大小的数据。实验表明：入队时，当数据比较小时Redis的性能要高于RabbitMQ，而如果数据大小超过了10K，Redis则慢的无法忍受；出队时，无论数据大小，Redis都表现出非常好的性能，而RabbitMQ的出队性能则远低于Redis。
  • ZeroMQ
    ZeroMQ号称最快的消息队列系统，尤其针对大吞吐量的需求场景。ZMQ能够实现RabbitMQ不擅长的高级/复杂的队列，但是开发人员需要自己组合多种技术框架，技术上的复杂度是对这MQ能够应用成功的挑战。ZeroMQ具有一个独特的非中间件的模式，你不需要安装和运行一个消息服务器或中间件，因为你的应用程序将扮演了这个服务角色。你只需要简单的引用ZeroMQ程序库，可以使用NuGet安装，然后你就可以愉快的在应用程序之间发送消息了。但是ZeroMQ仅提供非持久性的队列，也就是说如果down机，数据将会丢失。其中，Twitter的Storm中默认使用ZeroMQ作为数据流的传输。
  • ActiveMQ
    ActiveMQ是Apache下的一个子项目。 类似于ZeroMQ，它能够以代理人和点对点的技术实现队列。同时类似于RabbitMQ，它少量代码就可以高效地实现高级应用场景。
  • Kafka/Jafka
    Kafka是Apache下的一个子项目，是一个高性能跨语言分布式Publish/Subscribe消息队列系统，而Jafka是在Kafka之上孵化而来的，即Kafka的一个升级版。具有以下特性：快速持久化，可以在O(1)的系统开销下进行消息持久化；高吞吐，在一台普通的服务器上既可以达到10W/s的吞吐速率；完全的分布式系统，Broker、Producer、Consumer都原生自动支持分布式，自动实现复杂均衡；支持Hadoop数据并行加载，对于像Hadoop的一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka通过Hadoop的并行加载机制来统一了在线和离线的消息处理，这一点也是本课题所研究系统所看重的。Apache Kafka相对于ActiveMQ是一个非常轻量级的消息系统，除了性能非常好之外，还是一个工作良好的分布式系统。

Kafka解析

Terminology

  • Broker
    Kafka集群包含一个或多个服务器，这种服务器被称为broker
  • Topic
    每条发布到Kafka集群的消息都有一个类别，这个类别被称为topic。（物理上不同topic的消息分开存储，逻辑上一个topic的消息虽然保存于一个或多个broker上但用户只需指定消息的topic即可生产或消费数据而不必关心数据存于何处）
  • Partition
    parition是物理上的概念，每个topic包含一个或多个partition，创建topic时可指定parition数量。每个partition对应于一个文件夹，该文件夹下存储该partition的数据和索引文件
  • Producer
    负责发布消息到Kafka broker
  • Consumer
    消费消息。每个consumer属于一个特定的consuer group（可为每个consumer指定group name，若不指定group name则属于默认的group）。使用consumer high level API时，同一topic的一条消息只能被同一个consumer group内的一个consumer消费，但多个consumer group可同时消费这一消息。

Kafka架构

如上图所示，一个典型的kafka集群中包含若干producer（可以是web前端产生的page view，或者是服务器日志，系统CPU、memory等），若干broker（Kafka支持水平扩展，一般broker数量越多，集群吞吐率越高），若干consumer group，以及一个 Zookeeper 集群。Kafka通过Zookeeper管理集群配置，选举leader，以及在consumer group发生变化时进行rebalance。producer使用push模式将消息发布到broker，consumer使用pull模式从broker订阅并消费消息。

Push vs. Pull

作为一个messaging system，Kafka遵循了传统的方式，选择由producer向broker push消息并由consumer从broker pull消息。一些logging-centric system，比如Facebook的 Scribe 和Cloudera的 Flume ,采用非常不同的push模式。事实上，push模式和pull模式各有优劣。

push模式很难适应消费速率不同的消费者，因为消息发送速率是由broker决定的。push模式的目标是尽可能以最快速度传递消息，但是这样很容易造成consumer来不及处理消息，典型的表现就是拒绝服务以及网络拥塞。而pull模式则可以根据consumer的消费能力以适当的速率消费消息。

Topic & Partition

Topic在逻辑上可以被认为是一个在的queue，每条消费都必须指定它的topic，可以简单理解为必须指明把这条消息放进哪个queue里。为了使得Kafka的吞吐率可以水平扩展，物理上把topic分成一个或多个partition，每个partition在物理上对应一个文件夹，该文件夹下存储这个partition的所有消息和索引文件。


每个日志文件都是“log entries”序列，每一个 log entry 包含一个4字节整型数（值为N），其后跟N个字节的消息体。每条消息都有一个当前partition下唯一的64字节的offset，它指明了这条消息的起始位置。磁盘上存储的消费格式如下：

message length ： 4 bytes (value: 1+4+n)

“magic” value ： 1 byte

crc ： 4 bytes

payload ： n bytes

这个“log entries”并非由一个文件构成，而是分成多个segment，每个segment名为该segment第一条消息的offset和“.kafka”组成。另外会有一个索引文件，它标明了每个segment下包含的 log entry 的offset范围，如下图所示。


因为每条消息都被append到该partition中，是顺序写磁盘，因此效率非常高（经验证，顺序写磁盘效率比随机写内存还要高，这是Kafka高吞吐率的一个很重要的保证）。

每一条消息被发送到broker时，会根据paritition规则选择被存储到哪一个partition。如果partition规则设置的合理，所有消息可以均匀分布到不同的partition里，这样就实现了水平扩展。（如果一个topic对应一个文件，那这个文件所在的机器I/O将会成为这个topic的性能瓶颈，而partition解决了这个问题）。在创建topic时可以在 $KAFKA_HOME/config/server.properties 中指定这个partition的数量(如下所示)，当然也可以在topic创建之后去修改parition数量。 
# The default number of log partitions per topic. More partitions allow greater
# parallelism for consumption, but this will also result in more files across
# the brokers.
num.partitions=3

在发送一条消息时，可以指定这条消息的key，producer根据这个key和partition机制来判断将这条消息发送到哪个parition。paritition机制可以通过指定producer的paritition. class这一参数来指定，该class必须实现 kafka.producer.Partitioner 接口。本例中如果key可以被解析为整数则将对应的整数与partition总数取余，该消息会被发送到该数对应的partition。（每个parition都会有个序号）

import kafka.producer.Partitioner; import

阅读全文

MongoDB 3.2.x 分片搭建

发表评论
5台分片服务器建立 解压

tar zxvf /data/mongo.tgz -C /data mkdir /data/mongo/conf mkdir /data/mongo/logs mkdir /data/mongo/databases mkdir /data/mongo/databases/shard1 mkdir /data/mongo/databases/shard2 mkdir /data/mongo/databases/shard3 vi /data/mongo/conf/shard1.conf shardsvr=true replSet=shard1 port=10001 dbpath=/data/mongo/databases/shard1 logpath=/data/mongo/logs/shard1.log directoryperdb=true storageEngine=wiredTiger wiredTigerCacheSizeGB=2 syncdelay=30 wiredTigerCollectionBlockCompressor=zlib oplogSize=2048 logappend=true journal=false slowms=200 fork=true rest=true httpinterface=true vi

阅读全文

python使用esmre代替ahocorasick实现ac自动机[多模匹配]

发表评论

为什么会用AC自动机？ 如果你想知道一篇文章有没有你要过滤的敏感词，怎么办？ 不可能用正则一个个的匹配吧？  敏感词超过300个之后，用Trie来构建模式树 (字典树)的速度优势相当的明显… …

特别说下，trie图也是一种DFA，可以由trie树为基础构造出来，对于插入的每个模式串，其插入过程中使用的最后一个节点都作为DFA的一个终止节点。

如果要求一个母串包含哪些模式串，以用母串作为DFA的输入，在DFA 上行走，走到终止节点，就意味着匹配了相应的模式串。

ps: AC自动机是Trie的一种实现，也就是说AC自动机是构造Trie图的DFA的一种方法。还有别的构造DFA的方法…

不扯淡了，我们后端都是python写的，python的ahocorasick模块跟我们的业务不太匹配，问题是这样的 ！    如果你的服务是用来做敏感词匹配，也就是说所有文章里面只要含有一个关键词，那就说明匹配了。  但是我们的业务是文章中的所有能匹配到的关键词都一一的抽取出来。   我想有些朋友可能还不太明白，那么我举个例子， 如果我的关键词里面有宝马和马，那么用python的ahocorasick库只会得到宝马，而不会得到马。  问题是处在马这个字节是在宝马的链条里面的。  如何避开这个问题，我们也懒得自己重写了，已经有人给出了解决的模块。  已经测试完成，并上线使用了。

安装简单，直接pip install esmre

import esm
index = esm.Index()
index.enter("宝马")
index.enter("马")
index.enter("奔驰")
index.enter("保时捷")
index.fix()
index.query("哎呀，今天在楼下看到了宝马，我老家倒是有养马的，以前的邻居有个奔驰，不对是保时捷，大爷的，都是马")

再来一个完整的例子.  后续有时间我会把ac自动机的服务集成到rpc服务里面,然后用docker打包。

#coding:utf-8 import esm index = esm.Index() with open('keyword.config','r'

阅读全文

Kafka分区分配策略(Partition Assignment Strategy)

发表评论

目录

  • 1 问题
  • 2 Range strategy
  • 3 RoundRobin strategy

问题

用过 Kafka 的同学应该都知道，每个 Topic 一般会有很多个 partitions。为了使得我们能够及时消费消息，我们也可能会启动多个 Consumer 去消费，而每个 Consumer 又会启动一个或多个streams去分别消费 Topic 对应分区中的数据。我们又知道，Kafka 存在

阅读全文

mongodb通过$geoNear进行坐标检索

发表评论

最近的项目涉及带geo信息的多源数据融合，发现mongo3.x的geo检索跟2.x有点变化，在这里mark一下。

//1.建立geo索引 db.point.ensureIndex({"geo":"2d"}); //"geo"格式说明： [ 116.279943 #lng经度   40.049971, #lat纬度 ] //2.插入示例数据 db.point.insert({ "@id" : 1, "@geo" : [ 116.305297, 40.041993 ], "@bucket":["稻香村"], "@bucket_sign":["19d40bb2165c198560278e7bc3b2c5e5"] ,"name":"稻香村上地店"}) db.point.insert(

阅读全文

Kafka消息监控 – Kafka Eagle

发表评论

1.概述

在开发工作当中，消费 Kafka 集群中的消息时，数据的变动是我们所关心的，当业务并不复杂的前提下，我们可以使用 Kafka 提供的命令工具，配合 Zookeeper 客户端工具，可以很方便的完成我们的工作。随着业务的复杂化，Group 和 Topic 的增加，此时我们使用 Kafka 提供的命令工具，已预感到力不从心，这时候

阅读全文

Kafka设计与原理详解

发表评论

一、Kafka简介

本文综合了我之前写的kafka相关文章，可作为一个全面了解学习kafka的培训学习资料。

转载请注明出处 : 本文链接（http://blog.csdn.net/suifeng3051/article/details/48053965）

1.1 背景历史

当今社会各种应用系统诸如商业、社交、搜索、浏览等像信息工厂一样不断的生产出各种信息，在大数据时代，我们面临如下几个挑战：

  1. 如何收集这些巨大的信息
  2. 如何分析它
  3. 如何及时做到如上两点

阅读全文