订单 数据 全部 缓存 到本地MYSQL

老物流发货段 处理成 我们自己 物流 发货日报,以及物流跟踪形式

守护进程 : 回写 Ibm 数据库,交 由 IBM 和 澳优 处理 这事情

积分 编码 查询
1: 核对数据 库bianm 核对签名,核对后对应产品,
2: 核对已被查询 走老的 old check
3: 取出sku 发送 sku 给 Siebel crm,取回积分防伪结果
4: 本地缓存 sku ,销售类型,门店点,
5: 守护进程 : 转为 IBM 销售接口表 具体事务处理 ,非实时 .

现在 守护进程 任务 比较多
1: 取 YS物流编码,
2: 写入WX 格式 _serial _case, bianma 3个表
3: 取回订单交易表,交采集器处理
4: 回写订单交易单数量信息

1. select * from users where YEAR(adddate)<2007;

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

1. select * from users where adddate<‘2007-01-01’;

不使用NOT IN和<>操作

以上，就对其中MySQL索引类型进行了介绍。

OAuth是一个开放的认证协议，让你可以在防伪积分会员系统使用 新浪微博和google 登录认证。

OAuth有什么用？为什么要使用OAuth？

网络开放是一个不变的趋势，那么不可避免的会有各种网络服务间分享内容的需要。

举个我们身边国内的例子吧：比如人人网想要调用QQ邮箱的联系人列表，现在的方法是你需要在人人网输入你的QQ号，QQ密码才能调用，虽然网站上可能都自谓“不保留QQ用户名密码”，但是大家信吗？

OAuth就是为了解决这个问题而诞生的，用户访问第三方资源，不再需要网站提交你的用户名，密码。这样好处自己是安全，而且不会泄露你的隐私给不信任的一方。

OAuth原理

OAuth中有三方：一，用户；二，Consumer（不知杂翻译，类似上面的 twitterfeed 角色）；三，服务提供商（如上例的twitter角色）。

一，Consumer 向 服务提供商 申请接入权限

可得到：Consumer Key，Consumer Secret。twitter申请oauth的话，在 setting – connection – developer 里面申请。 同时给出三个访问网址：

1. request_token_url = ‘http://twitter.com/oauth/request_token’
2. access_token_url = ‘http://twitter.com/oauth/access_token’
3. authorize_url = ‘http://twitter.com/oauth/authorize’

二，当Consumer接到用户请求想要访问第三方资源（如twitter）的时候

Consumer需要先取得 请求另牌（Request Token）。网址为上面的 request_token_url，参数为：

1. oauth_consumer_key：Consumer Key
2. oauth_signature_method：签名加密方法
3. oauth_signature：加密的签名 （这个下面细说）
4. oauth_timestamp：UNIX时间戳
5. oauth_nonce：一个随机的混淆字符串，随机生成一个。
6. oauth_version：OAuth版本，可选，如果设置的话，一定设置为 1.0
7. oauth_callback：返回网址链接。
8. 及其它服务提供商定义的参数

这样 Consumer就取得了 请求另牌（包括另牌名 oauth_token，另牌密钥 oauth_token_secret。

三，浏览器自动转向服务提供商的网站：

网址为 authorize_url?oauth_token=请求另牌名

四，用户同意 Consumer访问 服务提供商资源

那么会自动转回上面的 oauth_callback 里定义的网址。同时加上 oauth_token （就是请求另牌），及 oauth_verifier（验证码）。

五，现在总可以开始请求资源了吧？

NO。现在还需要再向 服务提供商 请求 访问另牌（Access Token）。网址为上面的 access_token_url，参数为：

1. oauth_consumer_key：Consumer Key
2. oauth_token：上面取得的 请求另牌的名
3. oauth_signature_method：签名加密方法
4. oauth_signature：加密的签名 （这个下面细说）
5. oauth_timestamp：UNIX时间戳
6. oauth_nonce：一个随机的混淆字符串，随机生成一个。
7. oauth_version：OAuth版本，可选，如果设置的话，一定设置为 1.0
8. oauth_verifier：上面返回的验证码。
9. 请求 访问另牌的时候，不能加其它参数。

这样就可以取得 访问另牌（包括Access Token 及 Access Token Secret）。这个就是需要保存在 Consumer上面的信息（没有你的真实用户名，密码，安全吧！）

六，取得 访问另牌 后，

Consumer就可以作为用户的身份访问 服务提供商上被保护的资源了。提交的参数如下：

1. oauth_consumer_key：Consumer Key
2. oauth_token：访问另牌
3. oauth_signature_method：签名加密方法
4. oauth_signature：加密的签名 （这个下面细说）
5. oauth_timestamp：UNIX时间戳
6. oauth_nonce：一个随机的混淆字符串，随机生成一个。
7. oauth_version：OAuth版本，可选，如果设置的话，一定设置为 1.0
8. 及其它服务提供商定义的参数

OAuth安全机制是如何实现的？

OAuth 使用的签名加密方法有 HMAC-SHA1,RSA-SHA1 （可以自定义）。拿 HMAC-SHA1 来说吧，HMAC-SHA1这种加密码方法，可以使用 私钥 来加密 要在网络上传输的数据，而这个私钥只有 Consumer及服务提供商知道，试图攻击的人即使得到传输在网络上的字符串，没有 私钥 也是白搭。

私钥是：consumer secret&token secret （哈两个密码加一起）

要加密的字符串是：除 oauth_signature 外的其它要传输的数据。按参数名字符排列，如果一样，则按 内容排。如：domain=kejibo.com&oauth_consumer_key=XYZ& word=welcome………………….

前面提的加密里面都是固定的字符串，那么攻击者岂不是直接可以偷取使用吗？

不，oauth_timestamp，oauth_nonce。这两个是变化的。而且服务器会验证一个 nonce（混淆码）是否已经被使用。

那么这样攻击者就无法自已生成 签名，或者偷你的签名来使用了。

本文系原创，转换请注明链接，谢谢！

http://kejibo.com/oauth/

一，测试服务器配置：

Cpu: 2*4核Intel(R) Xeon(R) E5405 @ 2.00GHz

内存：4G

存储：36块1T的7.2K的SATA组成raid0。使用其中的1T

Mysql版本：5.1.45-community-log MySQL Community Server (GPL)

二，建测试表：

Myisam不分区不分表，单表10亿数据量：

create table biguser

(

ID bigint not null auto_increment comment ‘自增ID’,

Username varchar(30) not null comment ‘用户名’,

sex tinyint not null comment ‘性别’,

birthday datetime not null comment ‘生日’,

email varchar(50) not null comment ‘邮箱’,

tel int not null comment ‘手机’,

intro varchar(255) not null comment ‘个人简介’,

primary key (ID)

)

type = MYISAM

default charset=utf8;

Myisam不分区，分10个表，单表1亿数据量：

create table user01

(

ID bigint not null auto_increment comment ‘自增ID’,

Username varchar(30) not null comment ‘用户名’,

sex tinyint not null comment ‘性别’,

birthday datetime not null comment ‘生日’,

email varchar(50) not null comment ‘邮箱’,

tel int not null comment ‘手机’,

intro varchar(255) not null comment ‘个人简介’,

primary key (ID)

)

type = MYISAM

default charset=utf8;

*一共10个表,user01,user02,…,user10

Myisam用id进行hash分区，分10个区，每个分区1亿数据：

create table puser

(

ID bigint not null auto_increment comment ‘自增ID’,

Username varchar(30) not null comment ‘用户名’,

sex tinyint not null comment ‘性别’,

birthday datetime not null comment ‘生日’,

email varchar(50) not null comment ‘邮箱’,

tel int not null comment ‘手机’,

intro varchar(255) not null comment ‘个人简介’,

primary key (ID)

)

type = MYISAM

default charset=utf8

partition by hash(ID)

partitions 10;

Innodb用id进行hash分区，分10个区，每个分区1亿数据：

create table iuser

(

ID bigint not null auto_increment comment ‘自增ID’,

Username varchar(30) not null comment ‘用户名’,

sex tinyint not null comment ‘性别’,

birthday datetime not null comment ‘生日’,

email varchar(50) not null comment ‘邮箱’,

tel int not null comment ‘手机’,

intro varchar(255) not null comment ‘个人简介’,

primary key (ID)

)

type = Innodb

default charset=utf8

partition by hash(ID)

partitions 10;

Innodb不分区不分表，单表10亿数据量：

create table ibiguser

(

ID bigint not null auto_increment comment ‘自增ID’,

Username varchar(30) not null comment ‘用户名’,

sex tinyint not null comment ‘性别’,

birthday datetime not null comment ‘生日’,

email varchar(50) not null comment ‘邮箱’,

tel int not null comment ‘手机’,

intro varchar(255) not null comment ‘个人简介’,

primary key (ID)

)

type = Innodb

default charset=utf8;

三，数据生成

利用power design生成100万不重复的数据的基础表，然后将此表数据用mysqlslap工具重复插入到目标表，可以快速生成海量数量表。最终数据文件大小都在170G左右(分表情况单表17G数据文件)

插入100万记录到目标表的性能如下

单位（秒）：
Myisam不分区 Myisam分区 Innodb不分区 Innodb分区
10.514 9.114 16.258 16.893

可见非并发的大量数据插入myisam分区性能最佳，myisam不分区次之，innodb分区较差。

四，压力测试

利用mysql5.1自带的压力测试工具mysqlslap对以上四种情况进行了压力测试，测试结果如下(单位：秒)：
　 myisam
未分区 myisam
分区 Myisam
分表 Innodb
未分区 innodb
分区
100连续随机查询 4.55 4.11 5.389 4.445 5.893
　 　 　 　 　 　
并发50随机查询 0.052 0.049 0.075 0.07 0.038
并发100随机查询 0.071 0.078 0.11 0.088 0.055
并发250随机查询 0.137 0.153 0.239 0.175 0.124
并发500随机查询 0.266 0.273 0.447 0.283 0.24
并发1000随机查询 0.5 0.533 0.849 0.485 0.46
　 　 　 　 　 　
并发50随机插入 0.037 0.03 0.04 0.042 0.025
并发100随机插入 0.071 0.06 0.057 0.06 0.049
并发250随机插入 0.179 0.159 0.144 0.135 0.132
并发500随机插入 0.384 0.327 0.332 0.248 0.25
并发1000随机插入 0.82 0.73 0.737 0.542 0.526
　 　 　 　 　 　
并发50随机删除 1.204 1.536 0.196 0.041 0.039
并发100随机删除 2.333 2.945 0.362 0.062 0.063
并发250随机删除 5.568 5.718 0.831 0.14 0.173
并发500随机删除 9.663 9.705 1.42 0.275 0.308
并发1000随机删除 19.877 17.254 2.655 0.589 0.634
　 　 　 　 　 　
并发50随机更新 1.008 0.887 0.298 0.044 0.046
并发100随机更新 1.789 1.688 0.533 0.064 0.062
并发250随机更新 4.291 3.986 1.029 0.134 0.145
并发500随机更新 8.357 7.872 1.783 0.306 0.288
并发1000随机更新 15.963 15.126 3.33 0.575 0.563

*运行了一个100条语句的批查询，看非并发情况下的查询效率，查询语句见附一。

*利用存储过程进行一个hash处理，去对不同的表进行数据操作，见附二。

五，结论：

一，在高并发情况下，innodb的分区表的增，删，改，查的性能都优于myisam引擘，特别是在高并发删除和更新的场合下，两者相差可以达到20-30倍。

二，myisam的分区表(10个分区)和未分区表的性能相差不大，略优于未分区表。

三，myisam分区表(10个分区)的插入性能与分表(10个表)差不多，但查询性能要好30%左右。但删除与更新的性能分表要远远好于分区。

四，innodb分区表和未分区表查询和插入在低并发下，相差40%。但在并发性不断增加的情况下，性能相差不大。删除和更新性能则一直相近。
附一：

select sql_no_cache * from biguser where id= 14988469 ;

select sql_no_cache * from biguser where id= 57611709 ;

select sql_no_cache * from biguser where id= 88737417 ;

select sql_no_cache * from biguser where id= 5487431 ;

select sql_no_cache * from biguser where id= 75912772 ;

select sql_no_cache * from biguser where id= 39680341 ;

select sql_no_cache * from biguser where id= 33444232 ;

select sql_no_cache * from biguser where id= 53937959 ;

select sql_no_cache * from biguser where id= 29031225 ;

select sql_no_cache * from biguser where id= 1256108 ;

select sql_no_cache * from biguser where id= 25314369 ;

select sql_no_cache * from biguser where id= 24296361 ;

select sql_no_cache * from biguser where id= 65966713 ;

select sql_no_cache * from biguser where id= 14395018 ;

select sql_no_cache * from biguser where id= 69197350 ;

select sql_no_cache * from biguser where id= 90962562 ;

select sql_no_cache * from biguser where id= 67908690 ;

select sql_no_cache * from biguser where id= 34352967 ;

select sql_no_cache * from biguser where id= 76458078 ;

select sql_no_cache * from biguser where id= 9986401 ;

select sql_no_cache * from biguser where id= 92969693 ;

select sql_no_cache * from biguser where id= 21688034 ;

select sql_no_cache * from biguser where id= 23534033 ;

select sql_no_cache * from biguser where id= 49682571 ;

select sql_no_cache * from biguser where id= 70230582 ;

select sql_no_cache * from biguser where id= 23174504 ;

select sql_no_cache * from biguser where id= 54671332 ;

select sql_no_cache * from biguser where id= 60255403 ;

select sql_no_cache * from biguser where id= 33064209 ;

select sql_no_cache * from biguser where id= 30657185 ;

select sql_no_cache * from biguser where id= 98478707 ;

select sql_no_cache * from biguser where id= 27247625 ;

select sql_no_cache * from biguser where id= 20287058 ;

select sql_no_cache * from biguser where id= 67371577 ;

select sql_no_cache * from biguser where id= 18519687 ;

select sql_no_cache * from biguser where id= 55236080 ;

select sql_no_cache * from biguser where id= 21413273 ;

select sql_no_cache * from biguser where id= 2928926 ;

select sql_no_cache * from biguser where id= 82738229 ;

select sql_no_cache * from biguser where id= 47525876 ;

select sql_no_cache * from biguser where id= 19732304 ;

select sql_no_cache * from biguser where id= 63153463 ;

select sql_no_cache * from biguser where id= 1685048 ;

select sql_no_cache * from biguser where id= 4675229 ;

select sql_no_cache * from biguser where id= 14525956 ;

select sql_no_cache * from biguser where id= 86972953 ;

select sql_no_cache * from biguser where id= 21576455 ;

select sql_no_cache * from biguser where id= 5341705 ;

select sql_no_cache * from biguser where id= 66182739 ;

select sql_no_cache * from biguser where id= 54662774 ;

select sql_no_cache * from biguser where id= 59012070 ;

select sql_no_cache * from biguser where id= 52293127 ;

select sql_no_cache * from biguser where id= 29983640 ;

select sql_no_cache * from biguser where id= 21078779 ;

select sql_no_cache * from biguser where id= 14937593 ;

select sql_no_cache * from biguser where id= 17458594 ;

select sql_no_cache * from biguser where id= 7928885 ;

select sql_no_cache * from biguser where id= 73174679 ;

select sql_no_cache * from biguser where id= 21741457 ;

select sql_no_cache * from biguser where id= 86001336 ;

select sql_no_cache * from biguser where id= 52555158 ;

select sql_no_cache * from biguser where id= 23325556 ;

select sql_no_cache * from biguser where id= 63580254 ;

select sql_no_cache * from biguser where id= 83699681 ;

select sql_no_cache * from biguser where id= 10742003 ;

select sql_no_cache * from biguser where id= 81051582 ;

select sql_no_cache * from biguser where id= 45963004 ;

select sql_no_cache * from biguser where id= 95947261 ;

select sql_no_cache * from biguser where id= 19606015 ;

select sql_no_cache * from biguser where id= 24078829 ;

select sql_no_cache * from biguser where id= 676655 ;

select sql_no_cache * from biguser where id= 30713754 ;

select sql_no_cache * from biguser where id= 29905848 ;

select sql_no_cache * from biguser where id= 99763851 ;

select sql_no_cache * from biguser where id= 1495837 ;

select sql_no_cache * from biguser where id= 71316631 ;

select sql_no_cache * from biguser where id= 88798686 ;

select sql_no_cache * from biguser where id= 94214594 ;

select sql_no_cache * from biguser where id= 54310537 ;

select sql_no_cache * from biguser where id= 81828596 ;

select sql_no_cache * from biguser where id= 89927714 ;

select sql_no_cache * from biguser where id= 72684768 ;

select sql_no_cache * from biguser where id= 50764835 ;

select sql_no_cache * from biguser where id= 50720945 ;

select sql_no_cache * from biguser where id= 63690819 ;

select sql_no_cache * from biguser where id= 14890423 ;

select sql_no_cache * from biguser where id= 94762181 ;

select sql_no_cache * from biguser where id= 45487268 ;

select sql_no_cache * from biguser where id= 50795204 ;

select sql_no_cache * from biguser where id= 43415976 ;

select sql_no_cache * from biguser where id= 44953453 ;

select sql_no_cache * from biguser where id= 83626479 ;

select sql_no_cache * from biguser where id= 42730160 ;

select sql_no_cache * from biguser where id= 15229715 ;

select sql_no_cache * from biguser where id= 22058075 ;

select sql_no_cache * from biguser where id= 35277893 ;

select sql_no_cache * from biguser where id= 90205735 ;

select sql_no_cache * from biguser where id= 12501310 ;

select sql_no_cache * from biguser where id= 24653162 ;

select sql_no_cache * from biguser where id= 34248456 ;

附二：

use nopart ;

drop procedure p_hash_select;

delimiter //

create procedure p_hash_select(vid bigint)

begin

set @i=mod(vid,10);

if @i=1 then

select * from user01 where;

end if;

if @i=2 then

select * from user02 where;

end if;

if @i=3 then

select * from user03 where;

end if;

if @i=4 then

select * from user04 where;

end if;

if @i=5 then

select * from user05 where;

end if;

if @i=6 then

select * from user06 where;

end if;

if @i=7 then

select * from user07 where;

end if;

if @i=8 then

select * from user08 where;

end if;

if @i=9 then

select * from user09 where;

end if;

if @i=0 then

select * from user10 where;

end if;

end//

delimiter ;

You can use REPLACE INTO syntax if you want to overwrite an old record with a new one with the same key.

Or, you can use INSERT… ON DUPLICATE KEY UPDATE syntax if you want to perform an update to the record instead when you encounter a duplicate.

Edit: Thought I’d add some examples.

统一后的查询留言如下：

第二次查询及后续查询：
谨防假冒！该产品已被查询2次,查询首次查询时间为:
Beware of imitations! This product has been queried for 7 times, the time of first query is 2008-10-10 10:00:35.

防伪码长度错误，请重新输入则为:
Length of security code error, please re-enter.

防伪码错误，谨防假冒:
Security code error, and guard against counterfeiting

1:密码格式 : 头部共6位  123 位 为 批号  456位 为企业代号 ( 这种数据完全可以导入我们的防伪系统海量存储版本数据 )

导入 工作计时 为 2000万 每 天(产品 不多全部手工 导入重新登记)

明鉴提供的三种备份种类：完全备份、差异备份、增量备份。

完全备份：

备份全部选中的文件夹，并不依赖文件的存档属性来确定备份那些文件。（在备份过程中，任何现有的标记都被清除，每个文件都被标记为已备份，换言之，清除存档属性）。

差异备份：

差异备份是针对完全备份：备份上一次的完全备份后发生变化的所有文件。（差异备份过程中，只备份有标记的那些选中的文件和文件夹。它不清除标记，既：备份后不标记为已备份文件，换言之，不清除存档属性）。

增量备份：

增量备份是针对于上一次备份（无论是哪种备份）：备份上一次备份后，所有发生变化的文件。（增量备份过程中，只备份有标记的选中的文件和文件夹，它清除标记，既：备份后标记文件，换言之，清除存档属性。）

不同备份类型可以存在一定组合，参考示例如下：

完全备份和差异备份：

在星期一进行完全备份，在星期二至星期五进行差异备份。如果在星期五数据被破坏了，则你只需要还原星期一完全的备份和星期四的差异备份。这种策略备份数据需要较少的时间，但还原数据使用较少的时间。

完全备份和增量备份：

在星期一进行完全备份，在星期二至星期五进行增量备份。如果在星期五数据被破坏了，则你需要还原星期一正常的备份和从星期二至星期五的所有增量备份。这种策略备份数据需要较少的时间，但还原数据使用较多的时间。

$fangweiweburl50 = “http://localhost/encfwjituan/0qd86/qd315_webservice.php”;
这里是海量存储防伪数据库 存储是密码数据

http://localhost/encfwjituan/dump 是密码导入数据