支付寶開放平臺建立應用、用戶受權及應用受權java
1、建立應用mysql
一、登陸螞蟻金服開放平臺（open.alipay.com），web
二、進入開發者中心中，建立登記您的應用，並提交審覈，審覈經過後會爲您生成應用惟一標識（APPID）《開放平臺應用建立指南》算法
2、配置密鑰spring
一、 開發者調用接口前須要先生成RSA密鑰，RSA密鑰包含應用私鑰(APP_PRIVATE_KEY)、應用公鑰(APP_PUBLIC_KEY）。sql
二、生成密鑰後在開放平臺開發者中心進行密鑰配置，配置完成後能夠獲取支付寶公鑰(ALIPAY_PUBLIC_KEY) 注：生成密鑰方法鏈接（生成與配置），生成密鑰工具下載WINDOWS數據庫
3、搭建配置開發環境json
服務端SDK下載地址：SDK1.5api
AlipayClient alipayClient = new DefaultAlipayClient(URL, APP_ID, APP_PRIVATE_KEY, FORMAT, CHARSET, ALIPAY_PUBLIC_KEY, SIGN_TYPE);
關鍵參數（公共）說明:
| 配置參數 |
示例值解釋 |
獲取方式/示例值 |
| URL |
支付寶網關（固定） |
https://openapi.alipay.com/gateway.do |
| APPID |
APPID 即建立應用後生成 |
獲取見上面應用設置 |
| APP_PRIVATE_KEY |
開發者私鑰，由開發者本身生成 |
獲取詳見上面應用設置 |
| FORMAT |
參數返回格式，只支持json |
json（固定） |
| CHARSET |
編碼集，支持GBK/UTF-8 |
開發者根據實際工程編碼配置 |
| ALIPAY_PUBLIC_KEY |
支付寶公鑰，由支付寶生成 |
獲取詳見上面應用設置 |
| SIGN_TYPE |
商戶生成簽名字符串所使用的簽名算法類型，目前支持RSA2和RSA，推薦使用RSA2 |
RSA2 |
1.、用戶信息受權（用戶信息受權）
用戶信息受權主要是爲了獲取支付寶用戶ID（USER_ID）、受權令牌（access_token），便於開發者處理自身業務邏輯的時候使用
用戶信息受權URL拼裝規則：
https://openauth.alipay.com/oauth2/publicAppAuthorize.htm?app_id=APPID&scope=SCOPE&redirect_uri=ENCODED_URL
二、應用受權（應用受權概述）
應用受權URL拼裝規則：
https://openauth.alipay.com/oauth2/appToAppAuth.htm?app_id=APPID&scope=SCOPE&redirect_uri=ENCODED_URL
私有請求參數：
| 參數 |
參數名稱 |
類型 |
必填 |
描述 |
範例 |
| grant_type |
受權類型 |
String |
是 |
1.code換token 2.Refresh_token換 Token |
1.authorization_code 2. refresh_token |
| code |
受權碼 |
String |
否 |
|
bf67d8d5ed754af297f72cc482 |
| refresh_token |
刷新令牌 |
String |
否 |
與code二選一 |
201510BB0c409dd5758b4d939d4008a525X62 |
注：接口權限值，目前只支持auth_user（獲取用戶信息、網站支付寶登陸）、auth_base（用戶信息受權）、auth_ecard（商戶會員卡）、auth_invoice_info（支付寶閃電開票）、auth_puc_charge（生活繳費）五個值;
4、關於沙箱
沙箱是開放平臺提供給開發者用戶調試接口的環境，具體操做步驟見 沙箱接入指南。
獲取用戶信息沙箱接入注意點
一、獲取用戶信息支持沙箱接入；在沙箱調通接口後，必須在線上進行測試與驗收，全部返回碼及業務邏輯以線上爲準；
二、沙箱受權url連接拼接規則爲：
https://openauth.alipaydev.com/oauth2/publicAppAuthorize.htm?app_id=APPID&scope=SCOPE&redirect_uri=ENCODED_URL
做者 張, 偉發佈於 2017年9月20日分類 未分類
轉載地址：
http://blog.csdn.net/jiangzhexi/article/details/55817047?utm_source=itdadao&utm_medium=referral
軍規適用場景：併發量大、數據量大的互聯網業務
軍規：介紹內容
解讀：講解緣由，解讀比軍規更重要
1、基礎規範
（1）必須使用InnoDB存儲引擎
解讀：支持事務、行級鎖、併發性能更好、CPU及內存緩存頁優化使得資源利用率更高
（2）必須使用UTF8字符集
解讀：萬國碼，無需轉碼，無亂碼風險，節省空間
（3）數據表、數據字段必須加入中文註釋
解讀：N年後誰tm知道這個r1,r2,r3字段是幹嗎的
（4）禁止使用存儲過程、視圖、觸發器、Event
解讀：高併發大數據的互聯網業務，架構設計思路是「解放數據庫CPU，將計算轉移到服務層」，併發量大的狀況下，這些功能極可能將數據庫拖死，業務邏輯放到服務層具有更好的擴展性，可以輕易實現「增機器就加性能」。數據庫擅長存儲與索引，CPU計算仍是上移吧
（5）禁止存儲大文件或者大照片
解讀：爲什麼要讓數據庫作它不擅長的事情？大文件和照片存儲在文件系統，數據庫裏存URI多好
2、命名規範
（6）只容許使用內網域名，而不是ip鏈接數據庫
（7）線上環境、開發環境、測試環境數據庫內網域名遵循命名規範
業務名稱：xxx
線上環境：dj.xxx.db
開發環境：dj.xxx.rdb
測試環境：dj.xxx.tdb
從庫在名稱後加-s標識，備庫在名稱後加-ss標識
線上從庫：dj.xxx-s.db
線上備庫：dj.xxx-sss.db
（8）庫名、表名、字段名：小寫，下劃線風格，不超過32個字符，必須見名知意，禁止拼音英文混用
（9）表名t_xxx，非惟一索引名idx_xxx，惟一索引名uniq_xxx
3、表設計規範
（10）單實例表數目必須小於500
（11）單表列數目必須小於30
（12）表必須有主鍵，例如自增主鍵
解讀：
a）主鍵遞增，數據行寫入能夠提升插入性能，能夠避免page分裂，減小表碎片提高空間和內存的使用
b）主鍵要選擇較短的數據類型， Innodb引擎普通索引都會保存主鍵的值，較短的數據類型能夠有效的減小索引的磁盤空間，提升索引的緩存效率
c） 無主鍵的表刪除，在row模式的主從架構，會致使備庫夯住
（13）禁止使用外鍵，若是有外鍵完整性約束，須要應用程序控制
解讀：外鍵會致使表與表之間耦合，update與delete操做都會涉及相關聯的表，十分影響sql 的性能，甚至會形成死鎖。高併發狀況下容易形成數據庫性能，大數據高併發業務場景數據庫使用以性能優先
4、字段設計規範
（14）必須把字段定義爲NOT NULL而且提供默認值
解讀：
a）null的列使索引/索引統計/值比較都更加複雜，對MySQL來講更難優化
b）null 這種類型MySQL內部須要進行特殊處理，增長數據庫處理記錄的複雜性；同等條件下，表中有較多空字段的時候，數據庫的處理性能會下降不少
c）null值須要更多的存儲空，不管是表仍是索引中每行中的null的列都須要額外的空間來標識
d）對null 的處理時候，只能採用is null或is not null，而不能採用=、in、<、<>、!=、not in這些操做符號。如：where name!=’shenjian’，若是存在name爲null值的記錄，查詢結果就不會包含name爲null值的記錄
（15）禁止使用TEXT、BLOB類型
解讀：會浪費更多的磁盤和內存空間，非必要的大量的大字段查詢會淘汰掉熱數據，致使內存命中率急劇下降，影響數據庫性能
（16）禁止使用小數存儲貨幣
解讀：使用整數吧，小數容易致使錢對不上
（17）必須使用varchar(20)存儲手機號
解讀：
a）涉及到區號或者國家代號，可能出現+-()
b）手機號會去作數學運算麼？
c）varchar能夠支持模糊查詢，例如：like「138%」
（18）禁止使用ENUM，可以使用TINYINT代替
解讀：
a）增長新的ENUM值要作DDL操做
b）ENUM的內部實際存儲就是整數，你覺得本身定義的是字符串？
5、索引設計規範
（19）單表索引建議控制在5個之內
（20）單索引字段數不容許超過5個
解讀：字段超過5個時，實際已經起不到有效過濾數據的做用了
（21）禁止在更新十分頻繁、區分度不高的屬性上創建索引
解讀：
a）更新會變動B+樹，更新頻繁的字段創建索引會大大下降數據庫性能
b）「性別」這種區分度不大的屬性，創建索引是沒有什麼意義的，不能有效過濾數據，性能與全表掃描相似
（22）創建組合索引，必須把區分度高的字段放在前面
解讀：可以更加有效的過濾數據
6、SQL使用規範
（23）禁止使用SELECT *，只獲取必要的字段，須要顯示說明列屬性
解讀：
a）讀取不須要的列會增長CPU、IO、NET消耗
b）不能有效的利用覆蓋索引
c）使用SELECT *容易在增長或者刪除字段後出現程序BUG
（24）禁止使用INSERT INTO t_xxx VALUES(xxx)，必須顯示指定插入的列屬性
解讀：容易在增長或者刪除字段後出現程序BUG
（25）禁止使用屬性隱式轉換
解讀：SELECT uid FROM t_user WHERE phone=13812345678 會致使全表掃描，而不能命中phone索引，猜猜爲何？（這個線上問題不止出現過一次）
（26）禁止在WHERE條件的屬性上使用函數或者表達式
解讀：SELECT uid FROM t_user WHERE from_unixtime(day)>=’2017-02-15′ 會致使全表掃描
正確的寫法是：SELECT uid FROM t_user WHERE day>= unix_timestamp(‘2017-02-15 00:00:00’)
（27）禁止負向查詢，以及%開頭的模糊查詢
解讀：
a）負向查詢條件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，會致使全表掃描
b）%開頭的模糊查詢，會致使全表掃描
（28）禁止大表使用JOIN查詢，禁止大表使用子查詢
解讀：會產生臨時表，消耗較多內存與CPU，極大影響數據庫性能
（29）禁止使用OR條件，必須改成IN查詢
解讀：舊版本mysql的OR查詢是不能命中索引的，即便能命中索引，爲什麼要讓數據庫耗費更多的CPU幫助實施查詢優化呢？
（30）應用程序必須捕獲SQL異常，並有相應處理
總結：大數據量高併發的互聯網業務，極大影響數據庫性能的都不讓用，不讓用喲。
做者 小丑發佈於 2017年9月19日分類 未分類
1.老實辦法
我只有一分錢，可樂三塊錢一瓶。那我就只買1/300瓶好了。
2.拼單分享
我有一分錢，可樂三塊錢，那我找到其餘幾個想喝可樂但沒有三塊/喝不完一瓶的人湊足剩餘的2.99，買到可樂你們分。
3.交易增值
用一分錢換一根針，用一根針換一卷線，用一卷線換一個李子……最終經過交易疊加價值換到可樂。
4.搶佔最後最低價值
在一瓶可樂保質期到的前幾秒買下他。
5.覆蓋邊際成本
花900塊買300瓶雪碧，趁機向老闆提要求加一分錢讓他多送一瓶可樂。
6.尾單掃貨辦法
找到一家產值過剩倒閉的可樂廠，去庫房裏試着買一瓶。
7.誅心輿論辦法
大肆宣揚可樂有毒，等到可樂降價到一分。
8.炒做升值辦法
給手上的一分錢賦予其餘意義，直到它的市場價格超過可樂。
9.臭不要臉辦法
拿着一分錢，死皮賴臉問老闆要不給就在他店門口一哭二鬧三上吊。
10. 分期付款
第一期1分，第二期X元
還要更多有發散性的運營產品套路參考更多：http://www.pmcaff.com/discuss/index/919244833555520
做者 gf發佈於 2017年9月13日分類 產品
1 可點擊的按鈕或者連接或者總體圖片等可點擊的區域，鼠標移動上去都用手勢 ，不管是功能按鈕仍是連接等；
2 單選或者複選， 不該該只選擇小圖標的時候才能切換，應該是對應的文字或者區域均可以切換是否選中
做者 gf發佈於 2017年9月12日分類 交互
當在一個service的類中，當提交事務發生異常時，，企圖使用try{}catch防止前面的保存更新不回滾無效，好比在一個service方法同時有兩個與數據庫打交道的地方：
Order o=new Order();
//do set order 設置order的屬性….
this.orderService.saveOrUpdateOrder(o);//保存order
OrderExtend oe=new OrderExtend();
oe.setJobNum(o.getOrderNum());
//do set OrderExtend 設置OrderExtend的屬性….
/***************如下try企圖保證出異常時不讓order的數據回滾*****/
try {
this.orderExtendService.addOrderExtend(oe);//保存orderextend
} catch (Exception e) {
// TODO: handle exception
}
以上的代碼若是this.orderExtendService.addOrderExtend(oe);提交事務後發生異常，try{}catch並不起做用，order的保存照樣回滾。
那如何實現當OrderExtend 提交事務處問題時，不影響前面的事務呢，假如OrderExtend 的數據相對可有可無？
能夠經過不一樣的線程進行提交事務，至關於事務獨立開來：
/******************分開線程提交事務******************************************/
Order o=new Order();
//do set order 設置order的屬性….
this.orderService.saveOrUpdateOrder(o);//保存order
OrderExtend oe=new OrderExtend();
oe.setJobNum(o.getOrderNum());
//do set OrderExtend 設置OrderExtend的屬性….
/***************如下try企圖保證，出異常不讓order的數據回滾*****/
try {
//使用獨立線程進行orderExtend的保存，確保事務提交失敗不致使前面Order的保存的回滾
new Thread(new HttpUtil().buildRequest(dosaveOrderExtend(), oe, 10000, 10000, 「UTF-8」)).start();
} catch (Exception e) {
// TODO: handle exception
}
做者 宋, 金生發佈於 2017年9月11日2017年9月11日分類 java
第一步：在數據源配置文件阿里 druid數據庫鏈接池增長監聽過濾參數
代碼：
<!– 配置監控統計攔截的filters，去掉後監控界面sql沒法統計 –>
<beans:property name=「filters」 value=「stat,wall,log4j」 />
<!– 並在filters屬性中配置了log4j –>
<beans:property name=「proxyFilters」>
<beans:list>
<beans:ref bean=「stat-filter」 />
<beans:ref bean=「log-filter」 />
</beans:list>
</beans:property>
第二步：在web.xml增長Druid監控的Servlet
代碼：
<!– druid web 監控 –>
<servlet>
<servlet-name>DruidStatView</servlet-name>
<servlet-class>com.alibaba.druid.support.http.StatViewServlet</servlet-class>
<init-param>
<!– 用戶名 –>
<param-name>loginUsername</param-name>
<param-value>druid</param-value>
</init-param>
<init-param>
<!– 密碼 –>
<param-name>loginPassword</param-name>
<param-value>bounter</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>DruidStatView</servlet-name>
<url-pattern>/druid/*</url-pattern>
</servlet-mapping>
第三步：重啓項目訪問http://ip:端口/項目名/druid/index.html
如：http://test.blibao.com/sweep/druid/index.html
備註：監控內容包括sql監控，URI監控，session監控，Spring監控
Sql監控能夠看到項目裏全部執行的sql語句包括查詢、插入、刪除而且能夠按照執行時間排序方便發現項目內執行的慢sql，同時能夠找到哪些sql語句是經過HQL注入執行的。
URI監控能夠查看項目全部的訪問地址，方便發現哪些請求是高頻發生
Session監控能夠查看本次會話請求次數，方便哪些用戶在惡意訪問
轉載學習